darcs patch: Get External Core (-fext-core) working with readline

[Aaron Tomb]

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.