An Introduction to Monads in Scala

A Census Application

Assume you’re populating a database with people, and you have the following code:

case class Person(firstName: String, lastName: String) {
    // you have a requirement that these fields must not be nulls
    assert(firstName != null && lastName != null)
}

def getPerson(firstName: String, lastName: String): Person =
  if (firstName != null) {
    if (lastName != null) {
      Person(firstName.capitalize, lastName.capitalize)
    } else {
      null
    }
  } else {
    null
  }

This is a defensive Java-style implementation, which is hard to read, hard to debug and very easy to nest further. Notice the pattern: “extract” the first name, transform it, “extract” the last name, transform it, then wrap them into something interesting.

We can more elegantly solve this with Options. You’ve probably seen them before: they’re like lists, except they have at most one element. Options have both structural elements of monads: a “constructor” and a flatMap. We can therefore simplify this code:

def getPersonBetter(firstName: String, lastName: String): Option[Person] =
  Option(firstName).flatMap { fName =>
    Option(lastName).flatMap { lName =>
      Option(Person(fName.capitalize, lName.capitalize))
    }
  }

and we can then reduce this to for-comprehensions:

def getPersonFor(firstName: String, lastName: String): Option[Person] = for {
  fName <- Option(firstName)
  lName <- Option(lastName)
} yield Person(fName.capitalize, lName.capitalize)

Notice that it’s now much easier to read this code, because you have no more reason to do the null-checking logic in your head, you just leave to the Options. The null-checking part is the “interesting” thing they do.

Asynchronous Fetches

Imagine you’re calling some async services for your online store, like fetching from some external resource:

case class User(id: String)
case class Product(sku: String, price: Double)
// ^ never use Double for currency IN YOUR LIFE

def getUser(url: String): Future[User] = Future { ... }
def getLastOrder(userId: String): Future[Product] = Future { ... }

and assume I want to get Daniel’s last order from the store so I can send him a VAT invoice. However, all I know is the URL I need to call:

val userFuture = getUser("my.store.com/users/daniel")

Now what?

Beginners usually get stuck here: “how do I wait for this Future to end so I can get its value and move on with my life?”. So they onComplete the crap out of it:

userFuture.onComplete {
  case Success(User(id)) =>
    val lastOrder = getLastOrder(id)
    lastOrder.onComplete {
      case Success(Product(_, p)) =>
        val vatIncludedPrice = p * 1.19
        // then pass it on
    }
}

This is really bad, nested, hard to read and doesn’t cover all cases anyway. Notice you’re following the same ETW pattern: trying to extract an object, doing something with it and then wrap it back. Enter flatMaps again:

val vatIncludedPrice = getUser("my.store.com/users/daniel")
    .flatMap(user => getLastOrder(user.id)) // relevant monad bit
    .map(_.price * 1.19) // then do your thing

which you can then use to pass on to your logic computing VATs. Or even better:

val vatIncludedPriceFor = for {
  user <- getUser("my.store.com/users/daniel")
  order <- getLastOrder(user.id)
} yield order.price * 1.19

Double-For “Loops”

Lists follow the same pattern. Here’s an example: you want to return a “checkerboard” (i.e. a cartesian product) of all possible combinations of elements from two lists.

val numbers = List(1,2,3)
val chars = List('a', 'b', 'c')

Same pattern: get a value from numbers, get a value from chars, build a tuple from them, “repeat”. Solvable with flatMaps:

val checkerboard = numbers.flatMap(number => chars.map(char => (number, char)))

Or better:

val checkerboard2 = for {
  n <- numbers
  c <- chars
} yield (n, c)

which looks oddly similar to Java or imperative “loops”. The reason why this looks similar is that monads inherently describe sequential ETW computations: extract this, then transform, then wrap. If you want to process it further, same thing: extract, transform, wrap.

If you got this far, congratulations! The gist is this: whenever you need to ETW, you probably need a monad, which needs 1) a constructor, 2) a flatMap in the style of the above.

Left-Identity, A.K.A. the “If I Had It” Pattern

The ETW pattern is described in a single line: MyThing(x).flatMap(f). You can express that in two ways:

1. If you have the x the monad was built with, you want to apply the transformation on it, so you get f(x).
2. If you don’t, you need the ETW pattern, so you need MyThing(x).flatMap(f).

Either way, you get the same thing. For all monads, MyThing(x).flatMap(f) == f(x).

Left-Associativity, A.K.A. the Useless Wrap

Assume you have MySuperMonad(x). What should happen when you say

MySuperMonad(x).flatMap(x => MySuperMonad(x))

If it’s not obvious yet, make it concrete:

• Example with lists: List(x).flatMap(x => List(x)) = ?
• Example with Futures: Future(x).flatMap(x => Future(x))= ?

Nothing changes, right? An inherent property of monads is that MySuperMonad(x).flatMap(x => MySuperMonad(x)) is the same as MySuperMonad(x).

Right-Associativity, A.K.A. ETW-ETW

This one is critical, and describes the correctness of multiple flatMap chains on monads. Say you have a list and some transformations:

val numbers = List(1,2,3)
val incrementer = (x: Int) => List(x, x + 1)
val doubler = (x: Int) => List(x, 2 * x)

If you apply both transformations in flatMaps, you get:

[1,2,3].flatMap(incrementer).flatMap(doubler) =
[1,2,2,3,3,4].flatMap(doubler) =
[1,2,2,4,2,4,3,6,3,6,4,8]

Now, if you look at that list like this,

[1,2,2,4,  2,4,3,6,  3,6,4,8]

you can see which numbers were generated by each initial element of the list. In other words, we have

[
  incrementer(1).flatMap(doubler),
  incrementer(2).flatMap(doubler),
  incrementer(3).flatMap(doubler)
]

just as if a fictitious function x => incrementer(x).flatMap(doubler) was applied to each element. In other words,

numbers.flatMap(incrementer).flatMap(doubler) == numbers.flatMap(x => incrementer(x).flatMap(doubler))

Replace numbers with any monad and put any functions inside, and you get the boo-hoo-hoo scary axiom:

MyMonad(x).flatMap(f).flatMap(g) == MyMonad(x).flatMap(x => f(x).flatMap(g))

The pattern goes like this:

• Extract
• Transform & wrap
• Extract again
• Transform & wrap

which is what the two flatMaps do; in the right hand side we’re compressing the last 3 steps:

• Extract
• Transform & wrap & ETW