MonadPlus instance for ContT

[Edward Kmett]

I agree with Henning.

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 at henning-thielemann.de> wrote:

>
> On Mon, 24 Jun 2013, John Wiegley wrote:
>
>  Ross Paterson <R.Paterson at 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.
>>
>
> I guess that if someone has a MonadPlus monad, then he wants to continue
> to use it when the monad stack grows by a ContT. This would give preference
> to the second instance.
>
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130624/2daa1dfa/attachment.htm>