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?