darcs patch: Get External Core (-fext-core) working with
simonpj at microsoft.com
Tue Nov 7 08:46:44 EST 2006
| So, does anyone familiar with the renaming process for Haskell source
| have any suggestions as to the best way to accomplish the simpler
| Unique generation necessary for External Core?
The current ExtCore implementation is biased by its history. The best thing is to fix it so it makes sense on its own terms.
On the way *out* we convert
CoreSyn -> ExternalCore
Where 'ExternalCore' is a data type defined in module compiler/CoreSyn/ExternalCore.
On the way *in* we parse external core as HsExtCore (see compiler/hsSyn/HsSyn), which in turn contains
a) a bunch of TyClDecls (full Haskell)
b) a bunch of IfaceBinding
That really makes no sense; the reason for it is that we originally thought of ExtCore as a kind of user-readable version of a hi-file. But that didn't work for TyClDecls because we want to infer the kinds of type variables (mind you, we could revisit that choice).
Now that IfceBindings have Names, it makes even less sense. Furthermore, when Iface stuff is type-checked, GHC assumes that any type error is really a disaster (crash), whereas in user-written code it's perfectly routine to have type errors -- after all users might write Ext Core themselves.
My suggest is this.
* Treat an ExtCore module as a full Haskell module, with a [LHsDecl] inside it. (You could even nuke HsExtCore and use HsModule instead, but that might be going too far.)
* Add a new sort of binding to the data type HsBind, something like
data HsBind id = ... | CoreBind id (ExtCore id)
Here ExtCore is basically the data type Exp in the ExternalCore module, but parameterised over the type of identifiers. So we have
data ExtCore id = Var id | Dcon id | Lit Lit ... etc
* Extend the renamer to rename ExtCore RdrName to ExtCore Name
* Extend the type checker to typecheck ExtCore Name to generat ExtCore Id
* Extend the desugarer to desugar ExtCore Id to Core
The last three steps are 100% routine. And the ExtCore type is (by design) small.
All of this adds more code, but it's simple code, and I think you will find it more straightforward than trying to hack the current setup into shape.
If you like I can keep a tree on one side, so you can send me patches that do part of the job and then ask questions. That way we can discuss the code without having to commit to the HEAD till it's working.
Needless to say, a GHC-dev-wiki page describing the proposed design etc would be a wonderful thing.
More information about the Cvs-ghc