#10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can I make two pleas? 1. Could we cast this discussion in the language of type-indexed type representations `TTypeRep`, in [wiki:Typeable]? A `TTypeRep a` is very like `Typeable a`, but has the very great merit of being an ordinary data value. `Typeable a` is just the implicit version of it. You can get from one to the other via `tTypeRep`: {{{ class Typeable a where tTypeRep :: TTypeRep a }}} By using an ordinary data value we get away from talking about classes or superclasses or solvers or whatnot. Once we know, with forensic precision, what `TTypeable a` should do, then we can think about how the solver might generate `Typeable a` dictionaries, which are simply containers for a `TTypeable a` value. 2. Can we keep `TTypeRep` abstract, so instead of talking about what it "contains" we speak entirely in terms of what functions are available over it? `decomposeFun` is one such function. Now, for `kindRep` I think you are asking for a function {{{ kindRep :: forall (a::k). TTypeRep a -> TTypeRep k }}} And indeed it seems plausible that we should provide such a function, although I have seen no examples whatsoever of why it might be useful. (Producing a `TypeRep` only to print it does not count; there are easier ways of producing that sequence of characters.) I'm afraid I found the summary entirely opaque "The type inference and runtime representation should support constructing `Typeable (T :: k)`, even when ``k contains kind variables that are only mentioned in other `Typeable` constraints not necessarily involving the type constructor `T`. This will allow simple composition with polymorphic type constructors like `Proxy` and `Typeable` to work more naturally, but also more complicated things." What do you mean by "simple composition"? What do you mean by "more complicated things"? Don't answer directly: rather, just give a sequence of examples that you think should work. That will ''show'' me what "simple composition" means, rather than ''telling'' me! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10343#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler