More GND + role inference woes

[Richard Eisenberg]

Bah^2.

This is subtler than I thought.

See the ticket commentary here: http://ghc.haskell.org/trac/ghc/ticket/8503

Richard

On Nov 4, 2013, at 11:02 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Bah. This is a bug. I will fix.
> 
> Thanks for pointing it out!
> Richard
> 
> On Nov 4, 2013, at 10:37 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
> 
>> * Richard Eisenberg <eir at cis.upenn.edu> [2013-10-16 13:28:54-0400]
>>>> Moreover, I think this solves the other failures in http://www.haskell.org/pipermail/ghc-devs/2013-October/002961.html.  Here is one example, in that email.  smallcheck has this:
>>>> newtype Series m a = Series (ReaderT Depth (LogicT m) a)
>>>> deriving
>>>>   ( …,  MonadLogic)
>>>> 
>>>> where logict defines MonadLogic thus:
>>>> 
>>>> class (MonadPlus m) => MonadLogic m where
>>>>   msplit     :: m a -> m (Maybe (a, m a))
>>>> 
>>>> So the “bottom line” check above will attempt to find a cocercion betwem msplit’s type with m=Series m, and with m=ReaderT Depth (LogitT m).  Right?
>>> 
>>> Yes.
>>> 
>>>> So on the left of msplit’s arrow, we’ll ask can we prove
>>>> 
>>>>    Series m a ~R ReaderT Depth (LogicT m) a
>>>> 
>>>> Can we show that?  Yes, of course… that is the very newtype coercion for Series.
>>> 
>>> Well, it's the right-hand side of the arrow that's more troublesome, but that works out in this case, too.
>> 
>> I just tried compiling smallcheck with GHC HEAD, and it didn't work out:
>> 
>> Test/SmallCheck/SeriesMonad.hs:41:7:
>>     Can't make a derived instance of ‛MonadLogic (Series m)’
>>       (even with cunning newtype deriving):
>>       it is not type-safe to use GeneralizedNewtypeDeriving on this class;
>>       ‛msplit’, at type ‛forall a.
>>                          m a -> m (Maybe (a, m a))’, cannot be converted safely
>>     In the newtype declaration for ‛Series’
>> 
>> So GHC now looks at the methods, but the problem is still there.
>> 
>> What do you guys think?
>> 
>> I would agree that msplit's type is problematic (due to the nested m's),
>> but Simon and Richard previously said that it should work, so I'm
>> confused.
>> 
>> Roman
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>