Fine, then. If there are two classes to be had, why don't we add them and get it over with? Then the type signatures in the parsing library will make some kind of sense, and people will stop complaining about it, and the kittens will all have lots of yarn.

On Thu, Nov 6, 2014 at 9:43 PM, Edward Kmett <ekmett@gmail.com> wrote:
The operations from MonadPlus are the same as you'd get from Monad + Alternative. 

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.

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.

-Edward

On Thu, Nov 6, 2014 at 8:49 PM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 7 November 2014 12:36, David Feuer <david.feuer@gmail.com> wrote:
> Currently, Applicative is a superclass of Alternative. Unfortunately, the
> *only* laws for Alternative are the monoid laws. Sensible sets of laws have
> been proposed in the past, but unfortunately *none* of them cover all the
> current important instances. Thus we have a rather awkward situation where
> Alternative is a subclass of Applicative, but there's no real way to take
> advantage of that fact. There are essentially no useful functions that would
> end up with signatures that look like
>
> p :: (Applicative f, Alternative f) => ...
>
> I'm wondering, therefore, what people think of the idea of making
> Alternative entirely independent—just a version of Monoid with a different
> kind.
>
> class Alternative f where
>   empty :: f a
>   (<|>) :: f a -> f a -> f a
>
> A second option would be to go with a Functor superclass for Alternative;
> that might save some typing over the independent Alternative, and it comes
> with the free theorem
>
> fmap f empty = empty

Control.Applicative.optional requires (Functor f, Alternative f),
though that's the only function using Alternative that isn't a method
of the typeclass that's in there.

With AMP, what happens with MonadPlus?  Isn't it equivalent to
Monad+Alternative?
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries