<div dir="ltr">The operations from MonadPlus are the same as you'd get from Monad + Alternative. <div><br></div><div>That said, we don't actually have an extant proof that if you satisfy the Alternative laws and the Monad laws you satisfy the MonadPlus laws! Part of the problem is of course there are two sets of competing MonadPlus laws, so the question itself of whether such a proof can exist is rather ill-posed.<div><br></div><div>The AMP does not cover 'removing' dead-weight methods like mzero, mplus, return, etc. to get a more minimal subset, it just puts Applicative and Alternative in the class hierarchy where they belong so you don't constantly get stuck invoking liftM when working with transformers and the like.</div><div><br></div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 6, 2014 at 8:49 PM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 7 November 2014 12:36, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
> Currently, Applicative is a superclass of Alternative. Unfortunately, the<br>
> *only* laws for Alternative are the monoid laws. Sensible sets of laws have<br>
> been proposed in the past, but unfortunately *none* of them cover all the<br>
> current important instances. Thus we have a rather awkward situation where<br>
> Alternative is a subclass of Applicative, but there's no real way to take<br>
> advantage of that fact. There are essentially no useful functions that would<br>
> end up with signatures that look like<br>
><br>
> p :: (Applicative f, Alternative f) => ...<br>
><br>
> I'm wondering, therefore, what people think of the idea of making<br>
> Alternative entirely independent—just a version of Monoid with a different<br>
> kind.<br>
><br>
> class Alternative f where<br>
>   empty :: f a<br>
>   (<|>) :: f a -> f a -> f a<br>
><br>
> A second option would be to go with a Functor superclass for Alternative;<br>
> that might save some typing over the independent Alternative, and it comes<br>
> with the free theorem<br>
><br>
> fmap f empty = empty<br>
<br>
</div></div>Control.Applicative.optional requires (Functor f, Alternative f),<br>
though that's the only function using Alternative that isn't a method<br>
of the typeclass that's in there.<br>
<br>
With AMP, what happens with MonadPlus?  Isn't it equivalent to<br>
Monad+Alternative?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</font></span></blockquote></div><br></div>