On Nov 7, 2006, at 5:46 AM, Simon Peyton-Jones wrote:
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).
I had also started thinking that it seemed funny to do things that
way. I'm quite happy to do it more elegantly.
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.
Yes, I definitely think we should allow External Core to come from
unknown sources, and have nice error messages.
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.
Yes, it's more code, but it sounds like better code. I like it.
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.
That would be quite nice. Among other things, this would allow
changing the parser to _recognize_ external core first (and perhaps
always generate an empty module), and later extend it to actually
have useful semantic actions. I've been doing this in my local copy
to cut the task into smaller chunks.
Also, this would let us decide for certain on a concrete syntax
before changing the internal representation.
Needless to say, a GHC-dev-wiki page describing the proposed design
etc would be a wonderful thing.
I've updated the wiki with the design ideas you mentioned.
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
