Replacing Ty in ExternalCore with IfaceType

[Aaron Tomb]

I think that's a good risk to be aware of. One nice thing about the  
architecture under discussion, though, is that it shares much more  
code than the previous design. I wasn't a previous user of External  
Core, but it seems to me that it was allowed to bit-rot in part  
because it duplicated many things that existed elsewhere in the  
compiler (for instance, a data type representing types), which then  
became outdated when the main compiler data structures changed (such  
as when FC was introduced).

In Simon's proposed design, the HsType data type, for instance, is  
shared between Haskell and External Core, which makes sense because  
the two languages have a very similar type structure. However, since  
they have very different term structures, there would be distinct  
HsExpr and ExtCoreExpr data types. It would be very hairy, in just  
the way you're describing, if we used HsExpr to represent  
ExtCoreExpr, since HsExpr is such a richer language. Checking that an  
instance of HsExpr is valid External Core would be quite a pain.  
Checking that an HsType is valid for Exernal Core, however, seems  
like it should be pretty easy.

I could easily be missing some complications, though. I'm open to  
further suggestions.

Aaron

On Dec 6, 2006, at 6:45 AM, Kirsten Chevalier wrote:

>> Message: 4
>> Date: Tue, 5 Dec 2006 16:00:28 +0000
>> From: Simon Peyton-Jones <simonpj at microsoft.com>
>> Subject: RE: Replacing Ty in ExternalCore with IfaceType
>> To: Aaron Tomb <atomb at soe.ucsc.edu>,    "cvs-ghc at haskell.org"
>>         <cvs-ghc at haskell.org>
>> Message-ID:
>>
> [snip]
>> * Be careful to specify the sub-language of HsSyn that is ExtCore
>>
>
> This seems like asking for trouble, too, although I guess it depends
> on what you mean by "be careful" and "specify". I can imagine bugs
> potentially sneaking in when somebody makes a change to GHC without
> thinking about ExtCore (which is exactly what happened in the past),
> but I suppose that it's possible to implement some sort of
> ext-core-lint phase or something that checks that the ExtCore that GHC
> is generating is consistent with the specification. But, you would
> want to make sure that that phase was actually enabled when the test
> suite gets run.
>
> Cheers,
> Kirsten
>
> -- 
> Kirsten Chevalier* chevalier at alum.wellesley.edu *Often in error,  
> never in doubt
> "It ain't no hassle, it ain't no mess / Right now it's the only  
> power that I
> possess / these businessmen got their money, they got their  
> instruments of
> death / but I can make life, I can make breath" -- Ani DiFranco
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc