[Haskell-cafe] External Core
atomb at soe.ucsc.edu
Thu Feb 8 16:46:47 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