There is an instance Monoid a => Monoid (Const a b) for the Const functor from Control.Applicative. There is also an instance Monoid m => Applicative (Const m).
I would therefore expect that there is also an instance Monoid m => Alternative (Const m) that coincides with the one for Monoid. Is this just an omission that should be fixed, or is there a deeper reason?
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:
