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
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