Handling failure is probably the most important part of building reliable systems. Monads are a common method of encapsulating failure - for instance, `Option[T]`

returns either `Some(t)`

or `None`

, and `None`

represents the failure. But Monads do not actually have any mechanism for *handling* failure - in principle, a monad which has failed (whatever failure means) can never be resumed. The same is true for applicative functors.

Nevertheless, recovering from a failure is often desirable. This can sometimes be accomplished via ad-hoc methods on monadic types - e.g., `Option.getOrElse`

or `Future.fallbackTo`

. But these are less than desirable since they are far from generic - if you want to build a class which is generic in it's functor (e.g. `class FooM[T](monad: Applicative[T])`

) you simply cannot recover from a failure.

For this reason, the `Plus`

typeclass was created. `Plus`

encapsulates types which are a semigroup or monoid in addition to being a functor.

## MonadPlus in Haskell

In Haskell, the primary usage of this pattern is the `MonadPlus`

typeclass. It introduces a new operation `mplus :: m a -> m a -> m a`

and a new element `mzero :: m a`

which must satisfy the following laws:

```
mzero `mplus` x == x
x `mplus` mzero == x
(x `mplus` y) `mplus` z == z `mplus` (y `mplus` z)
```

provided of course that both sides can can be evaluated. (It is not always possible to evaluate both sides due to certain infinite structures.)

Additionally, the `MonadPlus`

typeclass interacts with the `Monad`

typeclass in the following way:

```
mzero >>= f == mzero
x >> mzero == mzero
```

### Maybe and List

A simple example will illustrate the point of `MonadPlus`

.

```
Prelude> import Control.Monad
Prelude Control.Monad> Just 5 `mplus` Just 7
Just 5
Prelude Control.Monad> Just 5 `mplus` Nothing
Just 5
Prelude Control.Monad> Nothing `mplus` Just 7
Just 7
Prelude Control.Monad> Nothing `mplus` Nothing
Nothing
```

So with `MonadPlus`

, the `mplus`

operation basically means "try the first argument, if it fails, fall back to the second argument".

With `List`

, `mplus`

is simple concatenation:

```
Prelude Control.Monad> [2,3] `mplus` [7]
[2,3,7]
```

## Plus in Scalaz

Scalaz takes a slightly more complicated approach. A `Plus`

trait exists, and it merely represents the fact that a Functor is also a semigroup:

```
trait Plus[F[_]] { self =>
def plus[A](a: F[A], b: => F[A]): F[A]
}
```

Then the `PlusEmpty`

represents the fact that this functor is also a monoid:

```
trait PlusEmpty[F[_]] extends Plus[F] { self =>
def empty[A]: F[A]
}
```

A Scalaz implicit provides the `<+>`

method:

```
Some(5) <+> None == Some(5)
None <+> None == None
List(2,3) <+> List(7) == List(2,3,7)
```

And similarly, the `mzero[F[T]]`

function provides the zero element:

```
mzero[Option[Int]] == None
mzero[List[String]] == List()
```

Note that unlike in Haskell, *the monadic structure is not required*. You can have a `Functor`

which satisfies `Plus`

or `PlusEmpty`

even if it is not a Monad.

### Don't confuse <+> and |+|

For every `PlusEmpty`

instance, Scalaz provides a `Monoid`

instance. But it's important not to confuse the `<+>`

and `|+|`

operators. Using the standard Scalaz implicits, the latter operator will sometimes build *nested* Monoids:

```
Some(1) |+| Some(2) == Some(3)
Some(1) <+> Some(2) == Some(1)
```

So in the case of `Option[Int]`

, the `<+>`

operator represents the fallback operation of the outer functor only. In contrast, `|+|`

attempts to make the inner argument into a semigroup as well (if it can). This applies to nested monoids as well:

```
Some(Some(1)) <+> Some(Some(2)) == Some(Some(1))
Some(Some(1)) |+| Some(Some(2)) == Some(Some(3))
Some(None) <+> Some(Some(2)) == Some(None)
Some(None) |+| Some(Some(2)) == Some(Some(2))
```

## Why it's useful

Using the `Plus`

typeclass allows you to write functions/classes which are generic in the underlying functor.

A common pattern in scala-land is to build a cache which returns an object wrapped in a functor. For example, spray caching returns values wrapped in a `Future`

:

```
trait SprayCache {
def get(k: K)(expr: =>Future[V]): Future[V]
}
```

(This is an example that is not identical to the Spray cache.)

On other occasions it might be useful to return a `Validation`

or even an `Option`

:

```
trait OptionalCache {
def apply(k: K)(expr: =>Option[V]): Option[V]
}
```

Now suppose we want to generalize - it's our goal to build a generic `CacheF`

trait which parameterizes the functor. I.e., it will be `CacheF[M[_],K,V]`

and the `apply`

method will return an `M[V]`

.
We can, in a very straightforward manner, build such a cache. All you need to implement is the `put`

method and the `getFromCache`

method, and only the latter of which actually returns an `M[V]`

:

```
trait CacheF[M,K,V] {
protected implicit val ap: ApplicativePlus[M]
def put(k: K, v: M[V]): Unit
protected def getFromCache(k: K): M[V]
def get(k: K)(expr: =>M[V]): M[V] = getFromCache(k) <+> {
val result: M[V] = expr
put(k,result)
result
}
}
```

This cache encapsulates the semantics of both the `SprayCache`

and the `OptionalCache`

- you pull an object out of the cache, and if it's a failure (or if the cache fails to return), then you fall back to actually computing the object. But it's important that all code is shared between both - the only code which isn't is the actual implementation details of `put`

and `getFromCache`

.

## Math is useful

I've often heard it said that higher math is not particularly useful for programming, at least if you are building CRUD apps. On this point I disagree. Although one can build a CRUD app via basic programming skills and sheer force of will, that doesn't mean knowing a little bit more math is useless. Even when building something as simple as a cache, a little bit of higher math can come in handy and make your code a bit more generic.

P.S. Injera, the library I'm working on uses this pattern in slightly more generality. Go check it out, it might come in handy.