Discussion: remove the Applicative superclass from Alternative

[David Feuer]

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 at 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 at gmail.com> wrote:
>
>> On 7 November 2014 12:36, David Feuer <david.feuer at 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?
>>
>> --
>> Ivan Lazar Miljenovic
>> Ivan.Miljenovic at gmail.com
>> http://IvanMiljenovic.wordpress.com
>> _______________________________________________
>> 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/20141106/44665c30/attachment.html>