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?