I've historically used the moral equivalent of the second one far more than the first.
I have used both though. For instance, Numeric.Covector in the algebra package is a semantically restricted form of Cont that uses the equivalent of the first method.
The second form goes out of its way to preserve more of the existing semantics of the transformer stack and I'd dare say that if such an instance was added, it'd be closer to the expected behavior for more users.
-Edward
On Mon, Jun 24, 2013 at 1:53 PM, Henning Thielemann
<lemming@henning-thielemann.de> wrote:
On Mon, 24 Jun 2013, John Wiegley wrote:
Ross Paterson <R.Paterson@city.ac.uk> writes:
Alistair Lynn has proposed the following instance:
instance (Monoid r, Monad m) => MonadPlus (ContT r m) where
mzero = ContT $ const $ return mempty
m `mplus` n = ContT $ \ c -> liftM2 mappend (runContT m c) (runContT n c)
but this would also be possible:
instance (MonadPlus m) => MonadPlus (ContT r m) where
mzero = ContT $ const mzero
m `mplus` n = ContT $ \ c -> runContT m c `mplus` runContT n c
Is one of them better?
I would think that allowing ContT to transform any Monad over any Monoid has
more utility than only transforming another MonadPlus. But I have no real
world data to back this up, just a hunch.