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
#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]: 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