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 | -----Original Message----- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Tomb | Sent: 04 December 2006 06:59 | To: [EMAIL PROTECTED] | Subject: Replacing Ty in ExternalCore with IfaceType | | Hi All, | | I've had a bit of time to work on External Core again, and I've come | across a potential simplification. I'd like to hear what the more | seasoned developers think of it. | | The current situation is that ExternalCore.lhs defines datatypes for | both expressions and types (Exp and Ty, respectively), and the | External Core parser uses IfaceType to represent type declarations, | and IfaceBndr to represent term declarations. | | A while back, Simon PJ suggested extending HsBind with an alternative | for External Core bindings, and using that instead of IfaceBndr for | term declarations. Unfortunately, the parser sometimes needs to parse | types that appear as components of terms (such as abstractions, and | case expressions), and sometimes needs to parse them as part of type | declarations. Thus, the parser either needs separate productions for | parsing types that appear in terms and in type declarations, or code | to convert between IfaceType and Ty. | | One way to simplify this situation would be to remove the Ty data | type altogether, and use IfaceType in ExternalCore. Code already | exists to parse External Core into an IfaceType representation, and | pretty-printing IfaceTypes shouldn't be any harder than pretty- | printing Tys. However, doing this would require ExternalCore, which | currently imports nothing at all, to import IfaceType. IfaceType, in | turn, imports a number of other modules. So ExternalCore would no | longer be so appealingly self-contained. | | Does anyone have a preference? Should I scrap Ty in favor of | IfaceType, or should I make the External Core parser slightly more | complex? | | Aaron | | _______________________________________________ | Cvs-ghc mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
