[GHC] #9123: Need for higher kinded roles

[GHC]

#9123: Need for higher kinded roles
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  7.8.2
  checker)                           |             Keywords:  Roles,
      Resolution:                    |  QuantifiedConstraints
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > Look at your "use given:" line. How is it working?

 Well, I'm sweeping a bit under the carpet.   The super-duper superclass
 machinery arranges that if you have
 {{{
 [G] forall p q. Coercible p q => Coercible (m p) (m q)
 }}}
 then you also have
 {{{
 [G] forall p q. Coercible p q => m p ~R# m q
 }}}
 and it's ''that'' Given that takes the step
 {{{
     [W] (StateT Int m (StateT Int m a))
         ~R#
         (StateT Int m (IntStateT  m a))

 --> (use given: forall p q. Coercible p q => m p ~R# m q)
     [W] Coercible (StateT Int m a)
                   (IntStateT  m a)
 }}}
 Now to prove that `Coercible` constraint we need `StateT Int m a ~R#
 IntStateT  m a`.

 --------------
 However, you are absolutely right. The Given we have
 {{{
 [G] forall p q. Coercible p q => Coercible (m p) (m q)
 }}}
 is not quantified over `forall m`; it only holds for `m`, and not for
 `StateT Int m`!  So my claim that you can use the Given is completely
 false. Sorry about that.

 ------------------
 > On the other hand, what happens if you defined StateT to be a newtype?
 If StateT were a newtype, then the solver could (plausibly) unwrap the
 newtype, and then the given would apply.

 Yes it can, and yes, it does!  The newtype-unwrapping rule precedes the
 tycon-decompostion rule in `can_eq_nc'`.   And indeed with the change from
 data type to newtype, the program in comment:29 compiles fine.  Your
 comment in comment:29 "-- could be a newtype, but that doesn't change my
 argument" is quite false.

 -------------
 Bottom line: I should comment the importance of unwrapping before
 decomposition.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9123#comment:53>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler