Estimated reading time: 14 minutes

We, developers, hate and love things continually. We start to take great pleasure using those things that make the "aha!" in our heads quickly. e.g. patterns, libraries and language features. But those we do not follow swiftly we discard them and sometimes hate them. The same happens with sophisticated terms which some functional hippie guys try to sell us in places like conferences or meetups, terms that seem to come from *The Lord of the Rings*.

We are developers, we speak semicolons and curly braces right? So why should these words matter? If you are involved with the Scala world maybe you already have heard concepts like *Monad*, *Functor* and many others coming from *mathematics*.

For the next few minutes, let’s discuss why I think it is important to know a quite bit about the ideas behind these notions. We are going to tackle *Monad*, *Functor*, *Natural Transformation* and we will see how they are related to *for comprehension* and *composition* in Scala boundaries.

This article will not be another Monad tutorial or Monad introduction due to my very limited knowledge on this and because there are already so many other articles about it that could make more justice to explaining Monad. Certainly, it is possible to write code not knowing about dark, antique math fundamentals. We have been doing it like this for many years.

So of course Scala language is not an exception, you can write code as traditionally as it has been done for decades.

With Scala you can gain huge benefits like conciseness and maintainability writing imperative code style, you just need follow OOP principles and follow best practices and naming conventions. You can write less verbose code than Java at least.

However, if your daily job uses Scala you probably prefer functional style, and who doesn't? We enjoy avoiding mutations, doing recursion and using Scala collections to do things like:

Since Scala obstruct deals directly with null values it provides to us utilities to deal with values which might not exist, one of them is `Option`

for example which possesses a repertoire of gadgets similar to the collections, like:

In both examples above there is an obvious common pattern that we see very often in our Scala code.

The `map`

function and `flatMap`

that we heavily used in `List`

, `Seq`

or in other parametric types like `Option`

, `Try`

, `Either`

or `Future`

, are there because all these type constructors are Monads and Functors.

Note: we are going to usetype constructorandparametric typeto refer to the same concept. An`Option[T]`

is atype constructorbecause it itself is not a type, we need to pass it a concrete type to create the final type e.gStringto create anOption[String].

Let's define what a Monad is and, as I said above, this would not be a Monad tutorial. I will neither give you a very strict definition nor repeat what other Monad articles say such as *"Monads are just chicken burritos o chicken wraps where the chicken is the type parameter"*. No. I just want to give a definition that suffices our Scala context and not one that would provoke a heart attack to some mathematicians who are already resting in their graves.

So we are going to say that a Monad `M`

is a parametric type `M[T]`

with two operations, `flatMap`

and `unit`

, that has to satisfy some laws.

In functional literature, `flatMap`

is more commonly known as `bind`

and has the following signature:

As Scala is both Functional and Object Oriented, the `flatMap`

function is defined inside a `trait`

or a `class`

, so we can use the parameter `m: M[T]`

in the implementation to refer to the instance itself which would be of type `M[T]`

.

On the other hand, `unit`

is just a constructor function that goes from `T`

to `M[T]`

(or `T => M[T]`

) in Scala each Monad has different names for it `unit`

operation. e.g:

`List is a Monad with unit(x) = List(x)`

`Set is a Monad with unit(x) = Set(x)`

`Option is a Monad with unit(x) = Some(x)`

Now let's see Functors.

Functor `F`

is a parametric type `F[T]`

with a `map`

operation. That has to satisfy some laws.

In other functional languages `map`

usually has a signature like `map(x: F[T], f: T => U): F[U]`

but again the fact that Scala is OO and `map`

operation always is defined on Functor itself we omit `x: F[T]`

and use `this`

in the body of the operation. Some Functors in Scala.

`List is a Functor with map(f: T => U):List[U] = List("1").map(e => e.toInt) `

`Set is a Functor with map(f: T => U):Set[U] = Set(2).map(_ + 2) `

`Option is a Functor with map(f: T => U):Option[U] = Option(true).map(_.toString).map(_.toUpperCase)`

In both definitions I mention laws, Monad laws and Functors laws. I think it's not necessary to talk about those laws because: first, I don't want us to get bored; and second, as I said we don't need a rigid definition for our (Scala) interests.

So what are Monads good for? Despite of what we usually believe, Monad is not about side effect or values that can be absent or values that will be available at some point the time. No, Monads are about composition-- just simple composition! For that reason its main operation (*flatMap*) is also known as *bind*, as I said before.

I once read that Monads were like semicolons in programming languages, we use them not just to delimit lines but to compose sentences sequentially.

With Monad we compose expressions that are passing their result downstream while we manipulate them in an harmonic way.

Scala has a built-in feature that is dedicated entirely to Monads. That is `for-comprehension`

. Scala's `for`

/`yield`

is more related with *Haskell's* `do`

/`return`

than *Java's* `for-each`

. Regardless of what we tend to think `for`

/`yield`

has nothing to do with collections but with Monad.

This is the same example of the top re-written using `for`

/`yield`

obtaining the same result.

`for`

/`yield`

can be thought as tweezers and magnifying glassess that allow us to look inside Monads, pick-up the contained value, transform it and drop it back to another Monad.

We can use `for`

/`yield`

for any Monad/Functor parametric type, in other words any type that has `flatMap`

,`map`

and `unit`

operations will be available for us to use it with `for-comprehension`

.

There is no need for it to be a type constructor coming in the Standard Library. We can use it with custom types created from scratch.

Let's see a runnable exercise in the Scala Repl.

We are going to define a `case class`

with the two operations `flatMap`

and `map`

inside it. Remember that *case classes* provide us an implicit `apply`

constructor function, so that would be the `unit`

operation.

We can see how our `GateToWorld`

type works with for-comprehension doing this simple composition

Compiler will look at `flatMap/map`

to extract values from objects `one`

, `two`

, `three`

in the `for`

block and it will figure out the `unit`

function to use it in the `yield`

block to construct a new Monad value with 6 in it. (`GateToWorld.apply`

or `new GateToWorld`

would be `unit`

)

The idea with Monad patterns is to try to assemble all our programs to avoid the need to deal with the *contained *value. For that reason, *getters* functions in Monad have scary names like *unsafePerformIO*, or other simples names that somehow using also terrifies us because we know they are the devil and can break our programs entirely, like `get`

from `Option`

or `head`

from `List`

.

Let's do another exercise using our same *custom useless* *Monad* `GateToWorld`

. The idea would be a tiny program with Inputs and Outputs to show how Monad fit in the entirely flow. So before we are going to refactor our Monad a bit to hide the contained value and define a *getter method* with an scary name to send a warning to whomever wants to access the value using it.

Now let's define a data model and some operations for our business.

We are going to compose a program which will ask for data to the employee, will do some stupid data transformation (*normalizeEmployee*) and will "save" that data in the "database" (faking it obviously)

Now let's run the program

As we could see `for-comprehension`

and Monads (any parametric type with`flatMap/map/unit`

operations) will give us, in my opinion, a wonderful way to deal with composition.

However, composition in Monad is restricted to each Monad type constructor, that means that we can not do something like:

Therefore we can't also do

That is because `flatMap`

in `List`

, for example, is defined to be something like

Where `f`

parameter needs to be a function from `A`

to `List[B]`

or any subtype of `GenTraversableOnce[B]`

(which is a supertype of List) so type system will complain if we try to put something like a function that goes from `A`

to `Either[B]`

that is the case of `Right.apply`

(one of the `unit`

operations for `Either`

).

Of course saying of above we can resolve this very simple

But we are going to complicate it a bit and introduce another fancy term. We said that `Either[_]`

and `List[_]`

/ `Seq[_]`

are Functors and Monads. So operations that go from one Functor to another Functor are called *Natural Transformation*. Exactly like `toSeq`

that we just used to convert `Either[_,Int]`

Functor to `Seq[Int]`

/`List[Int]`

Functor above.

a natural transformation provides a way of transforming one functor into another while respecting the internal structure.Wikipedia

Scala Standard Library's Functors already come with some *Natural Transformation* like `toOption`

, `toEither`

, `toLeft`

, `toRight`

, `toTry`

.

While we usually represent functions like this `f: A -> B`

, `g: B -> C`

in the functional and mathematical literature. A *Natural Transformation* is represented with a curly arrow as follows `f: A ~> B`

, `g: B ~> C`

just to denote that A,B and C are functors,(`A[_], B[_], C[_]`

).

For that reason, and the fact that Scala type system is crazy (in a good sense) and powerful, we might have seen in libraries like *Scalaz* and *Cats*, this curly arrow and others funny operators.

We will borrow a fragment of *Scalaz* *Natural Transformation* implementation just to see how they squeeze Scala type system to allow operators look like in the mathematical literature.

*Scalaz* Natural Transformation

As you can see they definitely complicate it. You will find many operations that already exist in the *Scala Standard Library* shown in these other libraries, *Scalaz* and *Cats*, in a different way. Another example is Monad's `flatMap/bind`

that we talked above, you might find it with the alias `def >>=[B](f: A => M[B]):M[B] = flatMap(f)`

.

I must confess although I am quite a fan of those awkwards operators, they don't help in an early research of these concepts.

So get back to *Natural Transformation*, the simple one, what is it good for?

*Natural Transformation* in addition with `flatMap`

can be very useful to *flatten* types.

How many of us have found ourselves struggling when using an API that returns something like:

When we just need a simple`List[Employee]`

, we usually resolve it with a lot of boilerplate code, with a lot of overusing pattern matching and with a lot of tedium.

But let see another way to deal with these nested types, *flattening* them, with `flatMap`

and *Natural Transformation*.

We said that what we just need a List of Employees, but don't forget that there can be exceptions also in that return type, so ideally we should *log* them somehow.

First let's stay with a List of Employee

Now let's go for the errors

There are better approaches than this, of course, like groupBy for example. I just wanted an use case to flatten.

The process of *flatten* can be thought of in two steps: first, we need to transform all inner parametric types to the most outer (in this case to *List[*]*) later we need to apply* *flatMap* *from the outer to the most inner (in this case the* *Option[]*).

Of course there are many other scenarios where *Natural Transformation* makes sense.

To conclude we had mentioned terms like *Monad*, *Functors* and we saw how they are intrinsically related with some implementation of Scala features.

We looked at how `for-comprehension`

,`Monad`

, `Functor`

and `Natural Transformation`

are means of composition.

The way that typically these concepts are presented or explained is not the most pragmatic way, perhaps for that reason I used to be identified with this title a few years ago. Although we can not deny it now, these terms are being used out there, we can see how many libraries are based in these foundations; even *Java 8* and *TypeScript*/Javascript have monadically type structures with *filter*, *map* and *flatMap* in their core (Optional, Stream in *Java* and Array in Javascript) so there should not be anything wrong in knowing where they come from.

I consider that studying and knowing about these ideas share the same importance as studying OOP patterns from books like e.g *Gang of Four Design Patterns*.

So don't be shy to say *Category theory* outloud and don't be mad if you listen to it.

The worst that could happen is that this guy appears if you say it three times.

And how cool would be that.