* Richard Eisenberg <[email protected]> [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
signature.asc
Description: Digital signature
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
