I've not found any previous discussions of this effort. I am unaware
of any identified obstacles. Here's my idea so far.
Disclaimer: this is my first foray into GHC internals; I'd appreciate
criticism before I wander into implementation.
1) add 'data Kind = Star | ToK' to Language.Haskell.TH.Syntax
2) add a field of type Kind to the Language.Haskell.TH.Info type's
TyConI, PrimTyConI, and TyVarI constructors.
3) adjust GHC's TcSplice.reifyTyCon function to provide these Kinds
(From what I can tell, the TyCon.tyConKind :: TyCon -> Kind and
Var.tyVarKind :: TyVar -> Kind functions pretty much provide what we'd
need. TcSlice.reifyName would need to change a bit, because the
TyVars' kind information is currently hidden behind the NamedThing
class.)
That's as far as I've thought it through. It would provide kind
information to the TH user, but not the ability to generate kind
signatures. To do so, it seems, would require adding the kind
information to the TH.Dec and TH.Type types instead of TH.Info (since
GHC's Convert module doesn't use TH.Info for generating HsSyn). Thus,
the alternative:
2') wherever [Name] occurs for a list of type variables, replace it
with [(Name, Kind)] (within within TH.Dec(DataD, NewtypeD, TySynD,
ClassD), TH.Con(ForallC), and TH.Type(ForallT))
Though this would burden the user with providing kind signatures for
all type variables - I suppose a sum type could be used instead of the
draconian pair. (The results of reify would always include the kind
(if it isn't star?).)
Backwards compatibility seems a lost cause, but the difference could
amount to little more than injection and projection with respect to
the TH datatypes for type variables.
How's it sound? Any pertinent wisdom out there?
