Question

I’ve been going through the Typeclassopedia to learn the type classes. I’m stuck understanding Alternative (and MonadPlus, for that matter).

The problems I’m having:

• the ‘pedia says that “the Alternative type class is for Applicative functors which also have a monoid structure.” I don’t get this — doesn’t Alternative mean something totally different from Monoid? i.e. I understood the point of the Alternative type class as picking between two things, whereas I understood Monoids as being about combining things.

• why does Alternative need an empty method/member? I may be wrong, but it seems to not be used at all … at least in the code I could find. And it seems not to fit with the theme of the class — if I have two things, and need to pick one, what do I need an ’empty’ for?

• why does the Alternative type class need an Applicative constraint, and why does it need a kind of * -> *? Why not just have <|> :: a -> a -> a? All of the instances could still be implemented in the same way … I think (not sure). What value does it provide that Monoid doesn’t?

• what’s the point of the MonadPlus type class? Can’t I unlock all of its goodness by just using something as both a Monad and Alternative? Why not just ditch it? (I’m sure I’m wrong, but I don’t have any counterexamples)

Hopefully all those questions are coherent … !

---

Bounty update: @Antal’s answer is a great start, but Q3 is still open: what does Alternative provide that Monoid doesn’t? I find this answer unsatisfactory since it lacks concrete examples, and a specific discussion of how the higher-kindedness of Alternative distinguishes it from Monoid.

If it’s to combine applicative’s effects with Monoid’s behavior, why not just:

liftA2 mappend

This is even more confusing for me because many Monoid instances are exactly the same as the Alternative instances.

That’s why I’m looking for specific examples that show why Alternative is necessary, and how it’s different — or means something different — from Monoid.

Answer 1

I won’t cover MonadPlus because there is disagreement about its laws.

---

After trying and failing to find any meaningful examples in which the structure of an Applicative leads naturally to an Alternative instance that disagrees with its Monoid instance*, I finally came up with this:

Alternative’s laws are more strict than Monoid’s, because the result cannot depend on the inner type. This excludes a large number of Monoid instances from being Alternatives.
These datatypes allow partial (meaning that they only work for some inner types) Monoid instances which are forbidden by the extra ‘structure’ of the * -> * kind. Examples:

• the standard Maybe instance for Monoid assumes that the inner type is Monoid => not an Alternative

• ZipLists, tuples, and functions can all be made Monoids, if their inner types are Monoids => not Alternatives

• sequences that have at least one element — cannot be Alternatives because there’s no empty:

  data Seq a
      = End a
      | Cons a (Seq a)
    deriving (Show, Eq, Ord)
  

On the other hand, some data types cannot be made Alternatives because they’re *-kinded:

• unit — ()
• Ordering
• numbers, booleans

My inferred conclusion: for types that have both an Alternative and a Monoid instance, the instances are intended to be the same. See also this answer.

---

_{excluding Maybe, which I argue doesn’t count because its standard instance should not require Monoid for the inner type, in which case it would be identical to Alternative}