#11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have an implementation of this [[https://github.com/ghc/ghc/compare/master...bgamari:wip/ttypeable|here]]. It's quite rough, there are a variety of interface questions that remain to be resolved, and I have yet to fix up a few Typeable uses in GHC itself (e.g. the `Binary` instances) which prevents me from finishing a stage2 build. That being said most of the groundwork has been laid, * `TTypeRep :: k -> *` has replaced `TypeRep` in the definition of `Typeable`. The constructors of `TTypeRep` are entirely hidden; there are pattern synonyms for querying for the applications and type constructors. * There exists a `TypeRep` which is simply a quantified `TTypeRep` * We have `tTypeRepKind :: TypeRep (a :: k) -> TypeRep k` * The solver now preserves enough information to construct these representations. This took a bit of gymnastics due to the recursive kind relations of `(->)`, `TYPE`, and `Levity`. These representations are handled as a bit of a special case. I need to * The desugarer can produce new `Typeable` dictionaries * I get much of the way through the stage2 build before failing as I haven't yet updated the instances in `Binary`. * `withTypeable` doesn't yet exist * In order to test things I have lifted the unsaturated-unlifted- application Core Lint check mentioned above * `TrTyApp` includes the kind of the application, which I only realized recently isn't necessary; it can be derived from the kind of the thing being applied. There are a number of interface questions that remain: * do we want to provide the continuation-style queries or only pattern synonyms? * what should the typical use-case of serialization look like? * do we want to provide "paranoid" equality checks which scrutinize the entire representation, in addition to the constant-time fingerprint-based checks? * should the pattern synonyms against `TrTypeRep` provide the kind of the term in addition to the type constructor/applied types? * the usual bike-shedding regarding naming has yet to happen That's pretty much the current state of things after spending the better part of last weekend on the project. Further progress will likely be slow until I have time again next weekend. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11011#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler