My 2p worth

- Making ExtCore more or less = IfaceSyn is probably a good plan.  Significant 
changes in IfaceSyn force changes in ExtCore, even if the latter is separately 
defined.

- I don't have a strong opinion about textual vs binary.  It's indeed an 
interesting idea to make Ext Core = .hi files with full bodies.

- It shouldn't be hard to clarify IfaceSyn's dependencies so that a standalone 
library that can read IfaceSyn could be carved out of GHC just by selecting 
modules X,Y and Z.  IfaceSyn is *designed* to have few dependences, so that it 
is easy to serialise.

Simon

| -----Original Message-----
| From: Neil Mitchell [mailto:[EMAIL PROTECTED]
| Sent: 02 July 2007 22:26
| To: Aaron Tomb
| Cc: Simon Peyton-Jones; [email protected]
| Subject: Re: More External Core questions
|
| Hi Aaron,
|
| > So, yeah, perhaps External Core should be essentially a textual
| > representation of a .hi file.
|
| Textual is something I doubt has much benefit. Yhc.Core has no textual
| syntax, and we've never wanted one. How about .hcr being just .hi but
| with complete bodies for all functions?
|
| If you do pick that route, you may end up with a lot less maintenance
| work, and can spend more time implementing a standalone library for
| reading GHC Core :-)
|
| Thanks
|
| Neil

_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to