## 1. Overview

As developers, we often encounter the need to encapsulate values with some additional context that cannot be directly related to the business domain. For example, we often need a value to be in a sequence or computed asynchronously.

Monads are the mechanism we can use to fulfill such needs. Let’s understand them by looking at some examples.

## 2. What Is a Monad?

**Monads are nothing more than a mechanism to sequence computations around values augmented with some additional feature**. The concept of monads comes directly from mathematics, precisely from category theory. For this reason, it’s often considered a tough topic. However, we’re going to make it as easy as possible.

As we said, a monad augments a value with some additional features. **Such features are called effects**. Some well-known effects are managing the nullability of a variable or managing the asynchronicity of its computation. In Scala, the corresponding monads to these effects are the *Option[T] *type and the *Future[T]* type.

As we can see, both types – *Option* and *Future* – define a type parameter. In fact, **a monad adds an effect to a value wrapping it around a context**. In Scala, one way to implement a monad is to use a parametric class on the type.

For example, let’s try to add to values of a generic type *T* the effect of laziness using monads. Hence, we define the *Lazy[A]* class as:

```
class Lazy[+A](value: => A) {
private lazy val internal: A = value
}
```

The *Lazy* type wraps a value of type *A*, provided by a “call-by-name” parameter to the class constructor to avoid eager evaluation.

### 2.1. Wrapping Values Inside a Monad: the *Unit* Function

First, **monads must provide a function that allows wrapping a generic value with the monad’s context**. We usually call such a function *unit*. It’s said that the *unit* function lifts the value in the monadic context. In Scala, we can use the *apply *method of a companion object to implement the *unit* function:

```
object Lazy {
def apply[A](value: => A): Lazy[A] = new Lazy(value)
}
```

In our example, the use of the *unit* function allows us to add the effect of the lazy initialization to a value, wrapping it inside the *Lazy* context:

```
val lazyInt: Lazy[Int] = Lazy {
println("The response to everything is 42")
42
}
```

Hence, the above code doesn’t print anything once executed because its execution’s laziness is lifted to monadic value.

### 2.2. Sequencing Computations Over a Value: the *flatmap* Function

However, the sole capability to add an effect to a monad isn’t worth the complexity added to the code. Moreover, we don’t want to extract the monad’s wrapped value to apply functions to it. It’s cumbersome and unmaintainable. **We need a mechanism to sequence computations over a value wrapped inside a monad**.

To overcome this problem, monads must provide the *flatMap* function. This function takes as input another function from the value of the type wrapped by the monad to the same monad applied to another type:

`def flatMap[B](f: (=> A) => Lazy[B]): Lazy[B] = f(internal)`

It transforms the value inside a monad into another value without performing any extraction to make it simpler. Hence, if we need to transform the *lazyInt *value into a *String*, we can use the *flatMap* function:

```
val lazyString42: Lazy[String] = lazyInt.flatMap { intValue =>
Lazy(intValue.toString)
}
```

Once again, no string will be printed to the standard output because of all the computation’s laziness. Moreover, we changed the value inside the monad without extracting it. So, any chain of *flatMap* invocation lets us make any sequence of transformations to the wrapped value.

### 2.3. Make It More Imperative: Using the For-comprehension

Last, but not least, we can define the *map* function for any monad in terms of the *flatMap* function:

`def map[B](f: A => B): Lazy[B] = flatMap(x => Lazy(f(x)))`

Why should we do that? Because for any type providing both the *map* and the *flatMap* functions in Scala, we can use the for-comprehension construct (see the article A Comprehensive Guide to For-Comprehension in Scala for further details). **The for-comprehension is quite useful for concatenating computations on the same monad**:

```
val result: Lazy[Int] = for {
first <- Lazy(1)
second <- Lazy(2)
third <- Lazy(3)
} yield first + second + third
```

As we can see, the above code is straightforward to read and lets us use the functional programming and monads in Scala as if we were coding using an imperative style.

For the sake of completeness, the above for-comprehension translates to calling the following sequence of functions:

```
val anotherResult: Lazy[Int] =
Lazy(1).flatMap { first =>
Lazy(2).flatMap { second =>
Lazy(3).map { third =>
first + second + third
}
}
}
```

It’s a terrific improvement, isn’t it?

## 3. The Awful Three: Monads’ Laws

However, with great power comes great responsibility. In fact, it’s not sufficient to add the *unit* and the *flatMap* functions to a type to make it a monad. The complex part comes with the mathematical laws the monad must fulfill.

The three monad laws are:

- Left identity
- Right identity
- Associativity

If the monad satisfies the three laws, then we guarantee that any sequence of applications of the *unit* and the *flatMap* functions leads to a valid monad — in other words, the monad’s effect to a value still holds.

**Monads and their laws define a design pattern from a programming perspective**, a truly reusable code resolving a generic problem.

Let’s describe them one by one.

### 3.1. Left Identity

The first of the three laws, called “left identity”, says that applying a function *f* using the *flatMap* function to a value *x* lifted by the *unit* function is equivalent to applying the function *f* directly to the value *x*:

`Monad.unit(x).flatMap(f) = f(x)`

If we take our *Lazy* monad, we have to prove that the following holds:

`Lazy(x).flatMap(f) == f(x)`

Hence, we can substitute *flatMap(f)* with *f(x)*, so the property holds by definition.

### 3.2. Right Identity

The second monadic law is called “right identity”. It states that application of the *flatMap *function using the *unit *function as the function *f* results in the original monadic value:

`x.flatMap(y => Monad.unit(y)) = x`

It’s easy to prove that our *Lazy* monad also fulfills this law:

`Lazy(x).flatMap(y => Lazy(y)) == Lazy(x)`

As we can substitute the term *flatMap(y => Lazy(y)) * with the result of the application, *Lazy(x)*, the property holds by definition.

### 3.3. Associativity

The last of the three monadic laws is the hardest to deal with and is called “associativity”. This law says that applying two functions *f *and* g *to a monad value using a sequence of *flatMap* calls is equivalent to applying *g* to the result of the application of the *flatMap* function using *f *as the parameter:

`x.flatMap(f).flatMap(g) = o.flatMap(x => f(x).flapMap(g))`

Hence, for the *Lazy *monad, the above rule becomes:

`Lazy(x).flatMap(f).flatMap(g) == f(x).flatMap(g)`

If we apply the substitution derived from the”left identity” law to the terms *Lazy(x).flatMap(f) *of the right side of the equation, we obtain exactly *f(x).flatMap(g)*. So, the associativity rule also holds for our monad 🙂

## 4. Bonus Methods

Until now, we presented the minimum set of methods that a monad must implement to adhere to the pattern. However, we can define many other methods to improve the usability of the *Lazy* type.

For example, we can implement the *flatten *function that removes a level of abstraction in nested monads’ types:

`def flatten(m: Lazy[Lazy[A]]): Lazy[A] = m.flatMap(x => x)`

Moreover, another interesting function to implement is the one that extracts the value contained in the monad. We can call it *get*:

`def get: A = internal`

When we call the *get* function, the lazy value is finally evaluated, performing any effect previously enclosed in the monad.

## 5. Conclusion

In this article, we introduced the concept of monads in Scala. We began by giving a simple definition of monads, and then we introduced the minimum set of functions that a monad must implement: the *unit* and the *flatMap*. Finally, we spoke about the three monad laws.

Finally, monads are a fascinating and useful concept that pervades many types in the Scala standard library. *Option*, *Future*, *Either*, and more or less all the collection types such as *List*, *Tree*, and *Map*, to name a few, are monads.

As always, the full source code of the article is available over on GitHub.

Nice job!

For any reader just setting out on the long journey to fully grokking the concept of monad, here is a diagram (attached image) from this slide deck, which shows the three minimal sets of combinators that are sufficient to define a monad.

Just to give any newbies to the monad laws a glimpse of how much simpler the three monadic laws are, when viewed in terms of Kleisli Composition, here is a diagram from this slide deck:

Thanks for the additions, Philip.

Nice article. A question, very loosely related to the article. Do a lot of people use spring with scala for web apps? In the scala echosystem you have play framework & http4s. I heard good things about spring, however, lots of examples are in java & kotlin. I’ve found this: https://hub.darcs.net/psnively/spring-scala/browse/mvc but I don’t know if it is up-to-date with the latest and greatest from spring.

Thanks

There are some people that do and it’s doable, but keep in mind that Spring Boot was never designed to be used with Scala, so I’d rather stick with native solutions to avoid potential issues