[Haskell-cafe] External Core

[Aaron Tomb]

Hi,

On more careful re-reading of the following email, which you sent at  
the beginning of December, I think perhaps you meant to say IfaceSyn  
where you said HsSyn?

That's what got me going down the path of implementing external core  
with HsSyn (and a special type for external core expressions distinct  
from HsExpr). It seemed like a great idea at the time, but it's  
definitely getting hairy now that I delve into it.

I think I also remember someone saying (though I can't find the email  
anymore) that it would be best to move away from using IfaceSyn on  
input, because its typechecker expects well-typed input and doesn't  
deal with errors nicely. Is there any intrinsic reason why it can't  
deal with errors better? Perhaps the best strategy is to use  
IfaceSyn, as before, and later, once it's working, improve the error  
handling in its typechecker.

Anyway, using IfaceSyn in both directions (your alternative (a)) is  
sounding better to me at this point. I'll get to work on it.

Thanks for all of the hand-holding. It's been quite helpful.

Aaron

> The present situation is very strange
> - On output we generate a program of type ExternalCore.Module
> - On input we generate a program of type HsSyn.Module
> The two data types are different in almost every respect.  This  
> seems to be asking for trouble.
>
> The reason we use HsSyn on input is so that we can share  
> typechecking code.  That is a good reason in my view.
>
> My suggestion (without a great deal of thought) would be
>
> * Dump the ExternalCore datatype entirely, or at least move it to a  
> reference implementation in a completely separate Darcs project.   
> (The reference impl could read the module, perform a no-op  
> transformation, and print it out again.)  The data type makes sense  
> as a way to define what ExtCore is, but it does not make sense as  
> part of GHC's implementation thereof, I think.
>
> * Use HsSyn for the output side, so that (parse (print p)) is the  
> identity.  That means that MkExternalCore would generate HsSyn; and  
> PprExternalCore would print the appropriate subset of HsSyn in  
> ExtCore syntax.
>
> * It also means we'd need to add a new constructor to  
> HsBinds.HsBind for ExtCore bindings of form x=e; plus of course a  
> supporting data type HsCoreExpr for the RHS.  We'd need new  
> typechecking code for HsCoreExpr; but the code in TcIface is really  
> the Wrong Thing for this -- it does not expect to find errors.
>
> * Be careful to specify the sub-language of HsSyn that is ExtCore
>
> Simon

On Feb 9, 2007, at 1:02 AM, Simon Peyton-Jones wrote:

> Aaron
>
> At the moment, on the way *out* of GHC, it goes like this:
>         Core --> converted to ExternalCore
>                 --> printed to file
>
> On the way *in* we see
>         file --> parsed to a mixture of HsSyn and IfaceSyn
>                 --> typechecked to Core
>
> This is all a bit of a (historically-derived) nonsense, as I think  
> we discussed.  And it gives rise to the problems you are seeing,  
> because the HsSyn part has this HsTyVarBndr etc.
>
> The same intermediate data type should be used in both directions.   
> I forget, but I think we discussed these alternatives
>         a) using IfaceSyn in both directions
>         b) or defining a new data type
>
> The advantage of (b) is that you can use a purpose-designed data  
> type.  But the disadvantage is that you need to write a type checker.
>
> I'd be inclined to try (a).  After all, that's the way that much of  
> the input side works already.  And IfaceSyn has stuff for  
> expressing data type declarations etc.  The advantage is that all  
> the typechecking part is already done.
>
>
> Does this ring any bells?
>