Discussion: remove the Applicative superclass from Alternative

[Edward Kmett]

This is a terrible breaking change that would do more damage to type
signatures across the entire ecosystem than almost anything else we could
do. There is a ton of code out there that just says 'Alternative f =>' out
there. It isn't a small breaking change you are proposing.

There is some relationship between Applicative and the associated
Alternative, usually a right-seminearring-like relationship with a
distributive law.

Sadly, Alternative suffers the same fate as MonadPlus in that it is
actually two classes in disguise with different but similar laws, depending
on if the Alternative is 'catch'-like or 'distributive'-like, but this
proposal doesn't fix that.

It just makes everyone do more work.

I'm very much -1 on this idea.

-Edward

On Thu, Nov 6, 2014 at 8:36 PM, 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
>
> _______________________________________________
> 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/cac0da42/attachment-0001.html>