[Haskell-cafe] External Core

Aaron Tomb atomb at soe.ucsc.edu
Thu Feb 8 16:24:52 EST 2007

On Feb 7, 2007, at 12:29 AM, Simon Peyton-Jones wrote:

> | I am still working on it. Some external events have slowed me down a
> | little (research, classes, appendicitis), and it has involved more
> | changes to the innards of GHC than anticipated, but it is still
> | moving along. If you can wait a little while, it should be possible
> | to use GHC.
> I'm delighted to hear it; thank you.  Maybe there are others who'd  
> like to join in?
> Keep me posted about those "changes to the innards" you mention!

Now that I've had a chance to revisit this code for the first time in  
a while, I think I'm stuck.

The difficulty comes from the change I mentioned in my previous  
reply: the KindedTyVar constructor in the HsTyVarBndr type used to  
associate a variable with a Kind. This was a quick shortcut in the  
past, because Haskell source doesn't contain complex kinds with  
variables that must be renamed and so forth. With External Core and  
FC's coercions, this assumption no longer holds. So, with the hope of  
sharing as much code as possible, I've made KindedTyVar associate  
each variable with an HsType (which encodes kinds similarly to how  
Type does in later stages).

Unfortunately, some code seems to depend on kinds being in the same  
form throughout much of the compilation pipeline. In particular, the  
code for type checking type and class declarations (typecheck/ 
TcTyClsDecls.lhs) maintains a kind environment which I believe is  
constrained to contain TcTyThings (though I'm not sure about this).  
At the very least, this environment seems to be intended to map  
variables to "processed" types or kinds (Type rather than HsType,  
etc.). Anyway, some of the functions in TcTyClsDecls.lhs, such as  
kcTyClDecl, take (variable, kind) pairs out of the environment and  
stick them back into HsSyn things, such as the tcdTyVars field of a  

I suspect it's possible to rewrite the type checking code to not do  
this, but I don't currently feel like I know enough about the  
intricacies of type checking full Haskell to do this. It might  
involve some serious changes. The only real alternative I see is to  
write a function that can convert fully-processed Kinds back into an  
HsType encoding. This seems like a nasty hack, though.

Does anyone with more experience with this area of the code have any  


More information about the Glasgow-haskell-users mailing list