Hi,
I encountered what might be a problem with parsing External Core
using HsType to represent types, though it might be possible to work
around it. It comes up when reading in a type variable with a kind
annotation which may be a type equality kind. These are represented
in HsType as the KindedTyVar alternative of HsTyVarBndr, which takes
a Kind as its second argument. However, Kind is just a name for Type
(not HsType), and thus it contains Names. Before type equality kinds
existed, this wasn't a problem, because no kind could contain type
variables. But now they can.
So, to properly construct an appropriate Kind seems like it would
require running the renamer early on (probably in the parser), which
sounds like a headache, if its even feasible at all.
Alternatively, we could ignore kind annotations in the parser (at
least for equality kinds) and create UserTyVars instead of
KindedTyVars. I believe it would then be possible to use existing
machinery to infer them later on (and, if I understand correctly, the
old implementation did this). Is it true that we can always infer kinds?
One problem with that approach, even if inference is no problem, is
that errors in kind annotations would be ignored. Maybe that doesn't
really matter.
In any case, it seems to make sense to leave kind annotations in the
concrete syntax for External Core, because even if GHC can infer
them, they might make other implementations that use External Core
somewhat easier.
Aaron
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
