More GND + role inference woes

Richard Eisenberg eir at
Mon Nov 4 16:02:25 UTC 2013

Bah. This is a bug. I will fix.

Thanks for pointing it out!

On Nov 4, 2013, at 10:37 AM, Roman Cheplyaka <roma at> wrote:

> * Richard Eisenberg <eir at> [2013-10-16 13:28:54-0400]
>>> Moreover, I think this solves the other failures in  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

More information about the ghc-devs mailing list