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 ClassDecl. 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 suggestions? Thanks, Aaron