Bah. This is a bug. I will fix. Thanks for pointing it out! Richard
On Nov 4, 2013, at 10:37 AM, Roman Cheplyaka <[email protected]> wrote: > * 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 _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
