We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies.

We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies. Less

We use cookies and other tracking technologies... More

# Login or registerto boost this post!

Show some love to the author of this blog by giving their post some rocket fuel đźš€.

# Login to see the application

Engineers who find a new job through Blockchain Works average a 15% increase in salary đźš€

# A Survival Guide to the Either Monad in Scala

Luca Florio 4 January, 2019 | 5 min read

## A survival guide to the Either monad in Scala

I started to work with Scala few months ago. One of the concepts that I had the most difficulties to understand is the `Either` monad. So, I decided to play around with it and better understand its power.

In this story I share what Iâ€™ve learned, hoping to help coders approaching this beautiful language.

`Either` is one of the most useful monads in Scala. If you are wondering what a monad is, wellâ€¦ I cannot go into the details here, maybe in a future story!

Imagine `Either` like a box containing a computation. You work inside this box, until you decide to get the result out of it.

In this specific case, our `Either` box can have two â€śformsâ€ť. It can be (`Either`) a `Left` or a `Right`, depending on the result of the computation inside it.

I can hear you asking: â€śOK, and what is it useful for?â€ť

The usual answer is: error handling.

We can put a computation in the `Either`, and make it a `Left` in case of errors, or a `Right` containing a result in case of success. The use of `Left` for errors, and `Right` for success is a convention. Letâ€™s understand this with some code!

In this snippet we are only defining an `Either` variable.

We can define it as a `Right` containing a valid value, or as `Left` containing an error. We also have a computation that return an `Either`, meaning it can be a `Left` or a `Right`. Simple, isnâ€™t it?

### Right and Left projection

Once we have the computation in the box, we may want to get the value out of it. Iâ€™m sure you expect to call a `.get` on the `Either` and extract your result.

Thatâ€™s not so simple.

Think about it: you put your computation in the `Either`, but you donâ€™t know if it resulted in a `Left` or a `Right`. So what should a `.get` call return? The error, or the value?

This is why to get the result you should make an assumption about the outcome of the computation.

Here is where the projection comes into play.

Starting from an `Either`, you can get a `RightProjection` or a `LeftProjection`. The former means that you assume the computation resulted in a `Right`, the latter in a `Left`.

I know, I knowâ€¦ this may be a little confusing. Itâ€™s better to understand it with some code. After all, code always tells the truth.

Thatâ€™s it. Note that when you try to get the result from a `RightProjection`, but it is a `Left`, you get an exception. The same goes for a `LeftProjection` and you have a `Right`.

The cool thing is that you can map on projections. This means you can say: â€śassume it is a `Right`: do this with itâ€ť, leaving the `Left` unchanged (and the other way around).

### From Option to Either

`Option` is another common way to deal with invalid values.

An `Option` can have a value or be empty (itâ€™s value is `Nothing`). I bet you noticed a similarity with `Either`â€¦ Itâ€™s even better, because we can actually transform an `Option` into an `Either`! Code time!

It is possible to transform an `Option` to a `Left` or a `Right`. The resulting side of the `Either` will contain the value of the `Option` if it is defined. Cool. Wait a minuteâ€¦ What if the `Option` is empty? We get the other side, but we need to specify what we expect to find in it.

### Inside out

`Either` is magic, we all agree on that. So we decide to use it for our uncertain computations. A typical scenario when doing functional programming is the mapping a function on a `List` of elements, or on a `Map`. Letâ€™s do it with our fresh new `Either`-powered computationâ€¦

Huston, we have a â€śproblemâ€ť (ok, itâ€™s not a BIG problem, but it is a bit uncomfortable). It would be better to have the collection inside the `Either` than lots of `Either` inside the collection. We can work on that.

#### List

Letâ€™s start with `List`. First we reason about it, then we can play with code.

We have to extract the value from the `Either`, put it in the `List`, and put the list inside an `Either`. Good, I like it.

The point is that we can have a `Left` or a `Right`, so we need to handle both cases. Until we find a `Right`, we can put its value inside a new `List`. We proceed this way accumulating every value in the new `List`.

Eventually we will reach the end of the `List` of `Either`, meaning we have a new `List` containing all the values. We can pack it in a `Right` and we are done. This was the case where our computation didnâ€™t return an `Error` inside a `Left`.

If this happens, it means that something went wrong in our computation, so we can return the `Left` with the `Error`. We have the logic, now we need the code.

#### Map

The work on `Map` is quite simple once we have done the homework for the `List` (despite needing to make it generic):

• Step one: transform the `Map` in a `List` of `Either` containing the tuple `(key, value)`.
• Step two: pass the result to the function we defined on `List`.
• Step three: transform the `List` of tuples inside the `Either` in a `Map`.

Easy Peasy.

### Letâ€™s get classy: a useful implicit converter

We introduced `Either` and understood it is useful for error handling. We played a bit with projections. We saw how to pass from an `Option` to an `Either`. We also implemented some useful functions to â€śextractâ€ť `Either` from `List` and `Map`. So far so good.

I would like to conclude our journey in the `Either` monad going a little bit further. The utility functions we defined do their jobs, but I feel like something is missingâ€¦

It would be amazing to do our conversion directly on the collection. We would have something like `myList.toEitherList` or `myMap.toEitherMap`. More or less like what we do with `Option.toRight` or `Option.toLeft`.

Good news: we can do it using implicit classes!

Using implicit classes in Scala lets us extend the capabilities of another class.

In our case, we extend the capability of `List` and `Map` to automagically â€śextractâ€ť the `Either`. The implementation of the conversion is the same we defined before. The only difference is that now we make it generic. Isnâ€™t Scala awesome?

Since this can be a useful utility class, I prepared for you a gist you can copy and paste with ease.

``````object EitherConverter {
implicit class EitherList[E, A](le: List[Either[E, A]]){
def toEitherList: Either[E, List[A]] = {
def helper(list: List[Either[E, A]], acc: List[A]): Either[E, List[A]] = list match {
case Nil => Right(acc)
case x::xs => x match {
case Left(e) => Left(e)
case Right(v) => helper(xs, acc :+ v)
}
}

helper(le, Nil)
}
}

implicit class EitherMap[K, V, E](me: Map[K, Either[E, V]]) {
def toEitherMap: Either[E, Map[K, V]] = me.map{
case (k, Right(v)) => Right(k, v)
case (_, e) => e
}.toList.toEitherList.map(l => l.asInstanceOf[List[(K, V)]].toMap)
}
}
``````

### Conclusion

Thatâ€™s all folks. I hope this short story may help you to better understand the `Either` monad.

Please note that my implementation is quite simple. I bet there are more complex and elegant ways to do the same thing. Iâ€™m a newbie in Scala and I like to KISS, so I prefer readability over (elegant) complexity.

If you have a better solution, especially for the utility class, I will be happy to see it and learn something new! :-)

Originally published on medium.freecodecamp.org

Luca Florio
Ph.D, passionate about Distributed Systems. Functional Programming Enthusiast. Krav Maga black belt.

## Related Issues

cosmos / gaia
• Started
• 0
• 7
• Intermediate
• Go
cosmos / gaia
• Started
• 0
• 3
• Intermediate
• Go
cosmos / ibc
• Started
• 0
• 2
• Intermediate
• TeX
cosmos / ibc
• Open
• 0
• 0
• Intermediate
• TeX

### Get hired!

#### Sign up now and apply for roles at companies that interest you.

Engineers who find a new job through Blockchain Works average a 15% increase in salary.