Monad Transformers in Scala — Unlocked
Let’s start with a question.
Do you think the type List is a Monad? Yes, it has got a bind (flatMap) and unit (apply) method that satisfy the requirements to be monad + it follows monad laws. The monad list can be also be termed as an effect because “given a type A, lifting it (somehow) as List adds new capabilities to it, such that, we can now aggregate over A, find the sum of A and so on and so forth. The type A never had these capabilities when it was existing by itself, until we lifted it to become a List. That was a deep dive straight away. Let’s take a breath now and say — Well, if you lift your type to a Monadic Effect, it now possess more capability. Get into a spaceship and say now YOU are capable of moving to space — Spaceship Monad!
Similarly, when we lift A to the effectOption, we say now A has another capability — A can have a defined absence — None. Now, we never want to throw new Exception to mark the absence of A.
Let’s lift the type A to another effect, scala.util.Try. Now A can be a Failure or a Success and not just A. The type A inherently has the capability to handle failure. I hope, you almost got the point now. This is more or less a conceptual understanding of what effects are, and we are naming it to be a “Monad”. Pause here and play with Monads.
Effect from a different angle
From another angle, we say any computation that should potentially yield A would become more intuitive and useful if it is yielding A under an effect, instead of a raw A . A typical example is trying to get an account from an account repository by passing an Id. If the computation has a return type of Account, it means, it should always exist. We want the computation’s return type to expose the fact that, account may or may not exist. In other words, it should return an Account under an effect — Option. Hence you may find the second get function in the below example to be more sensible.
Was that effect enough?
Well, we said the repository may or may not provide an account, and hence we returned an Option of account. We know the computation is under the effect Option. But is that enough to depict the behaviour of a database operation? What if the operation resulted in a database failure and you want to tell that to the user of the functionget?.This simply means the result should beeither a database exception or Option[A] . In other words, we need to lift Option[A] to another effect that can handle a database exception. We can use scalaz’s either \/ to depict this behaviour. The get function hence returns a DatabaseException \/ Option[A]. At this point you have fairly a complex return type that is basically a stack of two effects — Option and on top of it, \/[DatabaseException, ?].
Multiple Effects and Monad Transformers.
You are almost convinced that any computation can yield effects that are stacked upon each other similar to DatabaseException \/ Option[Account] . However, stacking the effects leads to difficulty in extracting the actual value that we need to further execute the rest of the computation with Account. We wish the stacked effect was just acting as one single effect — one single Monad, so that we can flatMap over it or map over it and continue the operation; something like this:
The only way to make that happen is Monad Transformers . We are saying we need a single effect that depicts the multiple layered effect. We use scalaz’s OptionTmonad transformer to depict the effect of returning a value under the effectOption which is in turn, under the effect \/ .
You might need to stare at it for a while. When you had another effect from thin air wrapping your actual effect, you somehow want to make sure that you still have the capability to peal off all your effects with a single operation (in this case, map)and get the value without any sort of nested for comprehensions, and that’s all MonadTransformer does! In the above example, the monad transformer OptionT converts an effect ofOption layered with \/[Throwable, ?]to one single effect OptionT that makes you feel like it is still an option and you are flatMapping over it.
Mechanism behind Monad Transformers (Skip it if you want to skip it)
Recently I have posted a better version of this explanation in my blog here: https://afsalthaj.github.io/myblog/posts/2018-04-16-monad-transformers.html
For those who want to know the mechanism behind monad transformers, you can easily identify it as composing monads, which is in fact a difficult task unlike applicatives, where the shapes are preserved. If you ever tried before to implement general monad composition, then you would have found that in order to implement join for nested monads F and G, you’d have to write a type such as F[G[F[G[A]]]=> F[G[A]] and that can’t be written generally. However, if G happens to have a traverse instance, we can sequence to turn G[F[_]] into F[G[_]], leading to F[F[G[G[A]]]], which in turn allow us to join the adjacent F layers as well as the adjacent G layers using their respective Monad instances. However take this with a grain of salt. It is not always true, a Traverse of G will help compose monads always.
The issue of composing monads is often addressed with a custom-written version of each monad that’s specifically constructed for composition. This kind of thing is called a monad transformer. The OptionT transformer mentioned above composes Option with any other Monad having a traverse instance.
Also its a general rule of thumb to identify layers as early as possible and get into Transformer as early as possible, and compose your executions without getting bloated. Quite often, we might end make things complicated with transformers and other monad abstractions such as Kleisli making the code a bit difficult to read, but its a team’s choice. Something like this:
My personal approach towards this problem, is to try and avoid the need of composing Monads if possible, because we have some smart monads available in libraries such as scalaz, cats and so forth that allow you to stay away from being complicated. Example, a Future that can return a disjunction (multiple layers) can be replaced with a single layer of scalaz.Task. If we think, we need to stack multiple effects then make sure you are getting into the monad transformer context as early as possible instead of pealing off abruptly certain part of the context to satisfy compiler. Anyways, we will discuss more on it soon.
Hope you enjoyed the read. Have fun!
