Haskell/Alternative and MonadPlus

In our studies so far, we saw that both  and lists can represent computations with a varying number of results. We use  to indicate a computation can fail somehow (that is, it can have either zero results or one result), and we use lists for computations that can have many possible results (ranging from zero to arbitrarily many results). In both of these cases, one useful operation is amalgamating all possible results from multiple computations into a single computation. With lists, for instance, that would amount to concatenating lists of possible results. The  class captures this amalgamation in a general way.

Definition
is a subclass of  whose instances must define, at a minimum, the following two methods:

is an applicative computation with zero results, while  is a binary function which combines two computations.

Here are the two instance definitions for  and lists:

Example: parallel parsing
Traditional input parsing involves functions which consume an input one character at a time. That is, a parsing function takes an input string and chops off (i.e. "consumes") characters from the front if they satisfy certain criteria. For example, you could write a function which consumes one uppercase character. If the characters on the front of the string don't satisfy the given criteria, the parser has failed. In the example below, for instance, we consume a digit in the input and return the digit that was parsed. The possibility of failure is expressed by using.

The guards assure that the  we are checking for is a single digit. Otherwise, we are just checking that the first character of our String matches the digit we are checking for. If it passes, we return the digit wrapped in a. Otherwise we return.

Now,  can be used to run two parsers in parallel. That is, we use the result of the first one if it succeeds, and otherwise, we use the result of the second. If both fail, then the combined parser returns. We can use  with   to, for instance, parse strings of binary digits:

Parser libraries often make use of  in this way. Two examples are  in  and   in. This usage pattern can be described in terms of choice. For instance, if we want to give  a string that will be successfully parsed, we have two choices: either to begin the string with   or with.

MonadPlus
The  class is closely related to  :

Its definition is the same as, except for different method names and the   constraint being changed into. Unsurprisingly, for types that have instances of both  and ,   and   should be equivalent to   and   respectively.

One might legitimately wonder why the seemingly redundant  class exists. Part of the reason is historical: just like  existed in Haskell long before   was introduced,   is much older than. Beyond such accidents, there are additional expectations (ones that do not apply to ) about how the   methods should interact with the , and therefore indicating that something is a   is a stronger claim than indicating that it is both an   and a. We will make some additional considerations about this issue in the following section.

Alternative and MonadPlus laws
Like most general-purpose classes,  and   are expected to follow a handful of laws. However, there isn't universal agreement on what the full set of laws should look like. The most commonly adopted laws, and the most crucial for providing intuition about, say that   and   form a monoid. By that, we mean:

There is nothing fancy about "forming a monoid": in the above, "neutral element" and "associative" here is just like how addition of integer numbers is said to be associative and to have zero as its neutral element. In fact, this analogy is the source of the names of the  methods,   and.

As for, at a minimum there usually are the monoid laws, which correspond exactly to the ones just above...

... plus the additional two laws, quoted by the documentation:

If  is interpreted as a failed computation, these laws state that a failure within a chain of monadic computations leads to the failure of the whole chain.

We will touch upon some additional suggestions of laws for  and   at the end of the chapter.

Useful functions
In addition to  and , there are two other general-purpose functions in the base libraries involving.

asum
A common task when working with  is taking a list of alternative values, e.g.   or , and folding it down with. The function, from   fulfills this role:

In a sense,  generalizes the list-specific   operation. Indeed, the two are equivalent when lists are the  being used. For Maybe,  finds the first   in the list and returns   if there aren't any.

It should also be mentioned that, available from both `Data.Foldable` and `Control.Monad`, is just   specialised to.

guard
When discussing the list monad we noted how similar it was to list comprehensions, but we didn't discuss how to mirror list comprehension filtering. The  function from   allows us to do exactly that.

Consider the following comprehension which retrieves all pythagorean triples (i.e. trios of integer numbers which work as the lengths of the sides for a right triangle). First we'll examine the brute-force approach. We'll use a boolean condition for filtering; namely, Pythagoras' theorem:

The translation of the comprehension above to a list monad do-block is:

The  function can be defined for all  s like this:

will reduce a do-block to  if its predicate is. Given the left zero law...

... an  on the left-hand side of an   operation will produce   again. As do-blocks are decomposed to lots of expressions joined up by, an   at any point will cause the entire do-block to become.

Let's examine in detail what  does in the. First, here is  defined for the list monad:

Basically,  blocks off a route. In, we want to block off all the routes (or combinations of  ,   and  ) where   is. Let's look at the expansion of the above -block to see how it works:

Replacing  and   with their definitions for the list monad (and using some let-bindings to keep it readable), we obtain:

Remember that  returns the empty list in the case of its argument being. Mapping across the empty list produces the empty list, no matter what function you pass in. So an empty list produced by the call to  in   will cause   to produce an empty list, with , which would otherwise add a result, not being actually called.

To understand why this matters, think about list-computations as a tree. With our Pythagorean triple algorithm, we need a branch starting from the top for every choice of, then a branch from each of these branches for every value of  , then from each of these, a branch for every value of. So the tree looks like this:

start |_________________________...   |    |         | z  1    2         3 |   |____     |____________    |    |    |    |       |    | x  1    1    2    1       2    3 |   |_   |    |___    |_   |    |    | |  |    | | |   | |  | y  1    1 2  2    1 2 3   2 3  3

Each combination of z, x and y represents a route through the tree. Once all the functions have been applied, the results of each branch are concatenated together, starting from the bottom. Any route where our predicate doesn't hold evaluates to an empty list, and so has no impact on this concatenation.

Relationship with monoids
While discussing the  laws above, we alluded to the mathematical concept of monoids. There is in fact already a  class in Haskell (defined in ). A thorough presentation of monoid will be given in a later chapter. However for now it suffices to say that a minimal definition of  implements two methods; namely, a neutral element (or 'zero') and an associative binary operation (or 'plus').

For example, lists form a simple monoid:

Looks familiar, doesn't it? In spite of the uncanny resemblance to  and , there is a key difference. Note the use of  instead of   in the instance declaration. Monoids are not necessarily "wrappers" of anything, or parametrically polymorphic. For instance, the integer numbers form a monoid under addition with   as neutral element. is a separate type class because it captures a specific sort of monoid with distinctive properties − for instance, a binary operation that is intrinsically linked to an   context.

Other suggested laws
Beyond the commonly assumed laws mentioned a few sections above, there are a handful of others which make sense from certain perspectives, but do not hold for all existing instances of  and. The current, in particular, might be seen as an intersection between a handful of hypothetical classes that would have additional laws.

The following two additional laws are commonly suggested for. While they do hold for both  and lists, there are counterexamples in the core libraries. Also note that, for s that are also , the   laws mentioned earlier are not a consequence of these laws.

As for, a common suggestion is the left distribution law, which holds for lists, but not for  :

Conversely, the left catch law holds for  but not for lists:

It is generally assumed that either left distribution or left catch will hold for any  instance. Why not both? Suppose they both hold. Then for any ,

This immediately rules out all but the most trivial  implementation. Even worse, it implies that for any,. Adding the monoid identity law  then implies that the monad has only one value, and is thus isomorphic to the trivial monad.

Finally, it is worth noting that there are divergences even about the monoid laws. One case sometimes raised against them is that for certain non-determinism monads typically expressed in terms of  the key laws are left zero and left distribution, while the monoid laws in such cases lead to difficulties and should be relaxed or dropped entirely.

Some entirely optional further reading, for the curious reader:


 * The Haskell Wiki on MonadPlus (note that this debate long predates the existence of ).
 * Distinction between typeclasses MonadPlus, Alternative, and Monoid? and Confused by the meaning of the 'Alternative' type class and its relationship to other type classes at Stack Overflow (detailed overviews of the status quo reflected by the documentation of the relevant libraries as of GHC 7.x/8.x − as opposed to the 2010 Haskell Report, which is less prescriptive on this matter.)
 * From monoids to near-semirings: the essence of MonadPlus and Alternative by Rivas, Jaskelioff and Schrijvers (a formulation that includes, beyond the monoid laws, right distribution and right absorption for, as well as left zero and left distribution for  ).
 * Wren Romano on MonadPlus and seminearrings (argues that the  right zero law is too strong).
 * Oleg Kiselyov on the MonadPlus laws (argues against the monoid laws in the case of non-determinism monads).
 * Must mplus always be associative? at Stack Overflow (a discussion about the merits of the monoid laws of ).