#8565: New GeneralisedNewtypeDeriving needs help with higher rank types -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: typecheck/should_compile/T8565 | Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by nomeata): Hmm, after more reading of the type class inference code I have doubts that this can be implemented without a larger refactoring of the the the typechecker and desugarer for instances. One of the reasons is that when `instance (forall a. (Coercible t1 t2)) => Coercible (forall a. t1) (forall a. t2)` were used when solving a constraint, the type variable will get turned into a parameter to the dictionary for the superclass, so is local to that. But if that constraint requires further instances, their dictionaries will require the same parameter, so this would require, in a way, a nested structure for the type class solver. The only work-around I can think of is asking the user to write the instance for `C` (or in the case of conduit, `MFunctor`) by hand. Which is unsatisfying. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8565#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler