#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