More External Core questions

[Aaron Tomb]

I think I'm convinced. Trying to make the format stay consistent has  
been the major thing that has slowed me down. The current syntax  
doesn't include all of the information contained in the iface data  
types, and inferring the missing bits is rather tricky. I had thought  
that inference of the missing details was possible, because some of  
what's in the internal data types is slightly redundant (in order to  
simplify much of the rest of GHC's code) but I'm getting to the point  
where I'm not quite sure.

So, yeah, perhaps External Core should be essentially a textual  
representation of a .hi file.

Beyond the details of function and type declarations, there's some  
other information that External Core never seemed to be designed to  
contain, but which might be useful. Class information, for instance,  
is currently missing, but is crucial in order to link Haskell code to  
External Core code for which the original Haskell source is unavailable.

Aaron

On Jul 2, 2007, at 11:38 AM, Neil Mitchell wrote:
> Backward compatibility got broken a while ago, since GHC Core
> currently doesn't seen to work. Given that you haven't got a slew of
> complaints when it got broken, I think you can assume that backward
> compatibility isn't that important.
>
>> The main reason I'd been avoiding the
>> Read/Show approach is that it would make the External Core format
>> change whenever the .hi format changes
>
> You have two choices:
>
> 1) Define a constant format, and then every time the .hi format
> changes update the output translator. This requires ongoing
> maintenance over a long time period. If this breaks, users will be
> unable to work with GHC Core anymore.
>
> 2) Use Read/Show based stuff. Every time the .hi format changes people
> may need to rework their program (unlikely) and will need to update
> their .hcr files. This gives you almost no ongoing maintenance.
>
> (1) is nicer for a user, but only if you guarantee it is going to be
> actively maintained. If there is any doubt about this, (2) would be
> preferable. Yhc uses a combination - a separate abstract syntax tree,
> but read/show off that.
>
> Thanks
>
> Neil