[GHC] #11011: Add type-indexed type representations (`TypeRep a`)

[GHC]

#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 goldfire):

 Replying to [comment:14 bgamari]:

 >  * 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

 [sic] Ooh. It's like a mystery novel. Perhaps having a type-safe language
 with both `* :: *` and self-reflective type representations shows that
 math is actually inconsistent and opened up a hole in spacetime through
 which bgamari has exited. :) I do hope that's not the case.

 Other points:

 * I vote only pattern synonyms.
 * Serialization is used in Cloud Haskell, no?
 * I like the idea of including the paranoid checks as an option for
 paranoid users. Although perhaps not, given that I believe it's likelier
 for a cosmic ray to flip a bit than for the fingerprints to give a false
 positive.

 As for names: I think a proper migration story needs to be articulated. In
 a few years, I'd hate to have all these extra `T`s lying around. Use a new
 module name for the new features and keep the old module with the old
 interface around? Maybe the new module can be `Data.Reflection`.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11011#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler