#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 goldfire): I like comment:7 and Simon's suggested implementation of comment:7 in comment:9. Ben's worry about redundant constraints floating around (comment:8) is a valid concern, but GHC already worries about this with any superclass constraints (as comment:9 hints). Re Simon's comment:12: You can't always pass the `TypeRep` for a kind separately. If you have the `TypeRep` for `(a :: k -> Type) (b :: k)`, then you don't always have the `TypeRep` for `k` to hand. `typeRepKind` allows you to get the kind once you've decompose an application. Also, while we're thinking about changing the concrete representation of `TypeRep`, might we consider getting rid of `TrFun`? GHC has very good reasons for having a streamlined representation for functions, but `TypeRep` doesn't have as clear-cut a use-case for this. Getting rid of `TrFun` would greatly simplify, e.g., `splitApp`. Was it motivated directly by performance (or other) problems? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14190#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler