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

GHC ghc-devs at haskell.org
Thu Sep 28 18:11:27 UTC 2017


#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


More information about the ghc-tickets mailing list