I believe there is a deeper reason. While it seems there is no canonical set of rules for Alternative
, in order for Alternative
to make sense, there definitely ought to be a relationship between Alternative
and its Applicative
operations (otherwise it'd be just an arbitrary monoid.)
This answer to Confused by the meaning of the 'Alternative' type class and its relationship to other type classes states these laws
- Right distributivity (of
<*>
): (f <|> g) <*> a = (f <*> a) <|> (g <*> a)
- Right absorption (for
<*>
): empty <*> a = empty
- Left distributivity (of
fmap
): f <$> (a <|> b) = (f <$> a) <|> (f <$> b)
- Left absorption (for
fmap
): f <$> empty = empty
which make a lot of sense to me. Roughly speaking, empty
and <|>
are to pure
and <$>
/<*>
what 0 and + are to 1 and *.
Now if we add instance Monoid m => Alternative (Const m)
that coincides with the one for Monoid
/ Applicative
, the Right- laws don't hold.
For example, 2. fails, because
empty <*> (Const x)
= Const mempty <*> Const x -- by the suggested definition of Alternative
= Const $ mempty `mappend` x -- by the definition of <*> for COnst
= Const x -- by monoid laws
which isn't equal to empty = Const mempty
. Similarly, 1. fails, a simple counter-example is setting f = Const (Sum 1); g = Const (Sum 1) ; a = Const (Sum 1)
.
See also:
Alternative
. LikeMonadPlus
, no one can even agree what its laws are supposed to be, and its most compelling use case is a sort of pun. Do whatever you want with it. – Rockoon