Aaron
| 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.
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
