[GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances

[GHC]

#14190: Typeable imposes seemingly redundant constraints on polykinded instances
-------------------------------------+-------------------------------------
        Reporter:  dfeuer            |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler (Type    |              Version:  8.2.1
  checker)                           |
      Resolution:                    |             Keywords:  Typeable
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4000
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 Replying to [comment:12 simonpj]:
 > > Without it, we have no way to get the kinds of the pieces once we
 decompose
 >
 > I think it would be useful to give a concrete example of this, and put
 that example in a Note with the code for `typeRepKind`.
 >
 > So far I have always supposed that it's a convenience mechanism: you can
 always pass a `TypeRep` for the kind separately.  But maybe I'm wrong.
 >
 > I'm not against `typeRepKind`, just wanting a slam-dunk argument that we
 need it.

 I haven't dug into enough examples of type reflection to know how often
 this is important. The one place I've seen so far is in de/serialization,
 where we need it if we want to check well-kindedness of deserialized
 typereps. Richard's suggestion that we dig into nested `App`s to find the
 constructor and build from there seems likely to be a good way to avoid
 needing a general `typeRepKind` there. For `dynApply`, storing the
 representation of the kind separately is sufficient, I think. But I don't
 know if some more sophisticated use of `Typeable` will really need kinds
 of deconstructed typereps.

 Ben: when we serialize a nest of applications, I think we probably don't
 want to emit a tag for each `App`. Use an `Apps` tag instead.

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