External Core in binary format

[Aaron Tomb]

We've been leaning away from having a specific data type for External  
Core, and just using the existing data types in GHC (such as  
IfaceExpr and CoreExpr). So it's unclear what data type we'd add  
deriving(Show) to. One of the major difficulties in having a standard  
external format is that GHC's internal data types often change, and  
having a separate data type for an external representation, with code  
to convert between internal and external formats involves a lot of  
duplication.

Aaron

On Jun 15, 2007, at 9:36 AM, Simon Peyton-Jones wrote:

> So I think what you want is a simple serialisation that can be read  
> easily by a program *any* language, not just Haskell.  That is, you  
> want to nail down the exact byte sequence generated; that keeps you  
> independent of minor variations in (say) the binary library.  For  
> that, s-expressions might do fine ... but the derived 'Show' would  
> also be just fine, and has the merit of being an existing  
> standardised format.  If you are worried about parsing performance,  
> that worry would probably apply equally to s-exps -- you can hand- 
> write Read if you want.
>
> It would make sense to use deriving(Show), and use a new class (or  
> simply function) for the current prettified syntax.  I don't think  
> anyone would object to such a change.
>
> S
>
> | -----Original Message-----
> | From: cvs-ghc-bounces at haskell.org [mailto:cvs-ghc- 
> bounces at haskell.org] On Behalf Of Neil Mitchell
> | Sent: 13 June 2007 18:56
> | To: chevalier at alum.wellesley.edu
> | Cc: Simon Marlow; cvs-ghc at haskell.org; Matthew Naylor
> | Subject: Re: External Core in binary format
> |
> | Hi
> |
> | > I'm not sure
> | > offhand why just doing Read/Show wouldn't work or didn't occur  
> to us;
> | > is there a reason why that wouldn't be straightforward?
> |
> | Talking to Matt, the only thing is that currently Show is used  
> for the
> | pretty printed version. Adding a new Ppr class and using that
> | shouldn't be that hard, then you can add the standard deriving
> | Read/Show. Read has rather bad performance, but the advantage of
> | immediately available and very little work might outweigh that.
> |
> | > > The other question is whether there will be a small  
> standalone library
> | > > called "GHC.Core" which lets a user load an abstract syntax  
> tree out
> | > > of a file?
> | >
> | > I think there should be, but AFAIK there's nothing in that  
> direction yet.
> |
> | If you do go down the Read/Show route then a copy of whatever file
> | defines the data type in a standalone library would be all that's
> | needed - possibly with the pretty printer, but that's not essential
> | for people who just want to consume Core.
> |
> | Thanks
> |
> | Neil
> |
> | _______________________________________________
> | Cvs-ghc mailing list
> | Cvs-ghc at haskell.org
> | http://www.haskell.org/mailman/listinfo/cvs-ghc
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc