Folks Ralf Laemmel and I have been making good progress with "scrap your boilerplate". (In fact there's a new paper at http://research.microsoft.com/~simonpj/papers/hmap/gmap2.ps; we'd love your comments.) Section 7 describes how to extend the Typeable story to higher kinds, in a manner that I know George Russell has already tried. It's rather beautiful, aside from the need to define a family of classes Typeable1, Typeable2, etc. But we've turned up a bad shortcoming in the Data.Typeable library. The present construction signature is like this: mkAppTy :: TyCon -> [TypeRep] -> TypeRep funTc :: TyCon mkFunTy :: TypeRep -> TypeRep -> TypeRep -- | Applies a type to a function type. Returns: @'Just' u@ if the -- first argument represents a function of type @t -> u@ and the -- second argument represents a function of type @t@. applyTy :: TypeRep -> TypeRep -> Maybe TypeRep What is missing is a function that takes two TypeReps and simply applies one to the other. So if one TypeRep is (ST T), and the other is Int, we want to build (ST T Int). The obvious name for this is 'applyTy' or 'mkAppTy', but they are both taken. Indeed, 'applyTy' is a bad name, because it only applies to *function* types. I'd like to suggest some re-naming mkTyConApp :: TyCon -> [TypeRep] -> TypeRep -- renaming of mkAppTy mkAppTy :: TypeRep -> TypeRep -> TypeRep -- new function mkFunTy -- no change funResultTy :: TypeRep -> TypeRep -> Maybe TypeRep -- ranming of applyTy I'm pretty sure about the first three. The last is the only "take this TypeRep apart" function that is currently offered, and it seems pretty specialised. Perhaps a more generic function would be splitTyConApp :: TypeRep -> (TyCon, [TypeRep]) (Remember, TypeReps only represent monotypes, so they are always a TyConApp.) Then we could build funResultTy from splitTyConApp. Is everyone happy with this? The main thing that seems unclear is what 'funResultTy' should be called. I guess we could just about stick with 'applyTy'. Opinions? Simon