Re: Discussion: remove the Applicative superclass from Alternative

6 Nov 2014


      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  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@gmail.com> wrote:
...
...
Currently, Applicative is a superclass of Alternative. Unfortunately,
...
*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
On 7 November 2014 12:36, David Feuer  wrote:
the
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@gmail.com
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries