[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):

 Re comment:7:

 Given our ideas in #11471, it's quite possible that the saturation check
 has gone stale. It does take a bit of Hard Thought, but my guess is that
 we can lift this restriction.

 Re comment:8:

 I'm afraid there are a few bugs in your code, and it's hard to disentangle
 what you're getting at.
 * The body of `proxyIntRep` is not what you mean. Perhaps you just meant
 `typeRep`?
 * The type of `proxyIntKind` is wrong. Why should it be `TypeRep (* ->
 *)`? I would think it's just plain old `*`, which is the kind of `Proxy
 Int`.
 * Your `TRFun` pattern would seem to want pattern signature `() => fun ~
 (arg -> res) => TTypeRep arg -> TTypeRep res -> TTypeRep fun`, no? That
 is, the equality is provided, not required.
 * Are you worried about decomposing `Proxy Int` itself? As in `case
 splitApp proxyIntRep of App trProxy _trInt -> typeRepKind trProxy`? But
 that would just be `* -> *` because the `Proxy` would still be specialized
 to `*`.

 Does this help to clarify? We absolutely need to only build kind-
 monomorphic `TypeRep`s, as described in the paper, but I don't see where
 things go awry under this scheme.

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