Hi everybody,

as I have recently had the need to look for a new job, I had several interviews as Scala Senior engineer. There is still this weird habit to be very specific in the technical question, as id **knowing Monads** make you more senior or a better developer than not knowing them.

So I ended up searching for information about Monads, that was one of the recurring questions for which I had no idea or answer before starting the round of interviews. And yes, there is a reason for which I had no idea, and the reason is embodied in what is called ** “the Crockford’s law”** that is basically a curse for which

*either you have never understood Monads*or

*when you understand it you lose the ability to clearly explain them to the rest of the world*.

For this reason I won’t try to explain Monads: I don’t need any curse, it is enough the bad luck that follows me. But I found a very interesting video that gives a nice and easy to understand overview of Monads. **This video is in English**, I am sure that youtube is full of explanations in other languages, but I found this one really simple to understand and I want to try to follow it in this post. First of all let’s share the video:

The explanation is a bit verbose because it explains lot of concepts that are really easy to remember for anyone who knows a bit of mathematics, so I would omit them here. The first important concept of the video is the one of **function**, nothing new. A function takes an argument of a type (for simplicity, in the first part of the video the type of the arguments is always **a**) and returns a value of a type (again, **a**).

The second important concept is the **monoids**: they are strictly bound to a concept of composition between functions. Let’s say that we have two functions:

**f: a -> a
g: a -> a**

We can compose them into a function **h: a -> a** by applying, to a variable **x** of type **a**, first **g** and the **f** to the result of **g** (so we compute **f(g(x)) **) or the opposite, **g(f(x))**. In a general way the **monoid** is *“a collection of things and a rule to combine them that, itself, should follow some rules”* and in the video the example of monoid is the clock: it’s hours are combined by the formula **(x+y)%12**. The rules that the combining rule should follow in a monoid are 2: associativity (meaning that *(x combined y) combined z = x combined (y combined** z)** *and indeed *(7+11%12)+8%12 = 7+(11+8%12)%12* ) and existence of unit element (meaning that there should exist an element of the collection **u** for which **u combined x = x combined u = x**, in the case of the clock this **u **is the value 12 for which (*x+12)%12=(12+x)%12=x*)

The step on **category theory** in which monads are better explained are only introduced in the video by saying that if we allow the previous functions **f** and **g** to have different types in input and output, we can compose them only in one way (so, if **f: a -> b **and **g: b -> c** we cannot compose them in **f(g(x))** but only in **g(f(x))** ).

Starting from the concept that functions, under compositions (with the same parameter type) are a monoid, we want to introduce compositions for functions that take an argument **a** but they transform it in a constructor that introduces something, calling it **Ma**. **Ma** is a construct that can be full of side effects (IO, exceptions, databases…). So we now have two functions:

**f: a -> Ma
g: a -> Ma**

and we want to combine them. We have to introduce an operator (**>>= **or *bind *in Huskell) that let us combine the two functions in such way that it takes **a** out of **Ma** from * f* and it push it in

**to return another**

*g***Ma**. So the combination of the two is expressed as a third function, like before, that takes as input

**x**of type

**a**, converts it into an

**Ma**and then, through

**>>=**recompute it through

*. In a more computer-like notation this is as following:*

**g****x => (Ma)(f(x)) >>= (Ma)(g(x))**

where **(Ma) **is a cast for making explicit the type. This new function we can express it as **h: a -> Ma** but this composition is totally in charge of the *bind* operator, that should be designed. As long as **Ma** is the same for * f* and

*we are in a monoid. But for making our*

**g****Ma**work as a monad, we have to design properly our

*bind*operator to keep the

**associativity**and the

**unit**.

Let’s jump to **Scala** and let’s see how those concept are translated to this language. The **unit** concept is not straightforward: *unit *is a kind of wrapper for a value that doesn’t change the value. In computer science world the wrapper is what makes **x **of type** a **becoming of type **Ma**. If I can spoiler that the class Option is a monad, we need a *unit* that is not changing **a** but that wraps our construct **Ma** to add side effects or IO or, in this case… nothing! Easier like that, our *unit* is the constructor of our monad.

And what is our *bind* operator? It is an operator, a function, that, applied to a function **f****: a -> Mb** and called on an object of type **Ma** returns an object of type **Mb**. Please note that this function does NOT force you to have only **a** as a type. But starting from a monad of type **a** it applies the function ** f** to that and construct a monad of the same type but with elements in

**b**. If you think to Option, or to List (also Lists are monads), which is the function that takes a List of elements, applies a function that for each of those elements creates another List of elements (eventually of different type), and it returns a List of the second type of elements? If you said

**map**… NO WAY! It is the

**flatMap**!!!

Please note that **map** can be defined in terms of **flatMap **and *unit* (constructor). Indeed:

**m map g = flatMap(x => unit(g(x)))**

and with this I think I said everything we have to say to introduce the monads in general and to give an idea of the mapping of monads in Scala.

Stay tuned!

## Leave a Reply