[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