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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries