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:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With