MonadPlus instance for ContT

[Dan Burton]

I also agree with Henning.

If anything, the 1st instance could be a ContT instance for Monoid.

instance (Monoid r, Monad m) => Monoid (ContT r m a) where
  mempty = ContT $ const $ return mempty
  m `mappend` n = ContT $ \ c -> liftM2 mappend (runContT m c) (runContT n
c)

That way both behaviors are easily accessible. Is there any other sensible
ContT instance for Monoid?

-- Dan Burton


On Mon, Jun 24, 2013 at 11:23 AM, Edward Kmett <ekmett at gmail.com> wrote:

> 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>
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130624/1ea8fbe9/attachment-0001.htm>