Discussion: remove the Applicative superclass from Alternative

[Ivan Lazar Miljenovic]

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