ScalaFP: Firsthand With Scala-Cats Monads – #1

In the previous post, we had a look at the reasons behind the monads and how monads can help us design the programs in a functional style. Now we are going to explore some of the monads which are frequently used in the applications but not available within the Scala predefined libraries. We will be exploring the monads which are provided by the scala-cats functional library.

Scala-Cats library contains a lot of monads for some specific task and also contain a common trait for describing the structure of monad like map, flatMap and pure  methods as below:

trait Monad[F[_]] {
  def pure[A](a: A): F[A]

  def flatMap[A, B](fa: F[A])(f: A => F[B]): F[B]

  def map[A, B](fa: F[A])(f: A => B): F[B] = {
    flatMap(fa)(a => pure(f(a)))
  }
}

Another thing, scala-cats monads syntax have come from various packages like, cats.syntax.functors, cats.syntax.applicative and cats.syntax.flatMap. The reason is that the Monads are functors as well as applicative. Cats handle flatMap as an independent trait (FlatMap) because in some of the scenarios we don’t want to handle the pure method which is also mentioned in the documentation like :
“We can implement a map or a flatMap that transforms the values of Map[K, ?], but we can’t implement pure (because we wouldn’t know what key to use when instantiating the new Map)”

Today we are going to explore only 2 of the monads from the Scala cats :

1. Identity Monad
2. Eval Monad

Identity Monad:

Identity monad is one of the most interesting monads in scala-cats, which is most commonly used and we will be discussing one of the scenarios today. The code definition of Identity monad is:

type Id[A] = A

Id contains nothing, but it is just an alias of normal value which wraps into some type called Id. But scala-cats Monads, Functors, and FlatMap allow us to call the map, flatMap and pure methods on Id type.

Let’s try to implement Id monad behaviors with the custom implementation below:

type Id[A] = A
def pure[A](value: A): A = value
def map[A, B](fa: Id[A])(f: A => B): Id[B] = f(fa)
def flatMap[A, B](fa: Id[A])(f: A => Id[B]): Id[B] = f(fa)

Now the question that comes to our mind is “What is the benefit of Id monad if it is just a  simple normal value? ”

Answer: Okay, First let’s have a look at the below example.

In the above example, we are creating a generic method which accepts int of monad type and performs a square of the elements. We are performing the operation with Option and `List` monads and getting the successful result but while we are passing the normal integer value, we will get a compile-time error. In that case of reusability, scala-cats provides us an Identity (Id) monad for dealing with generics monad methods with simple or normal values. In the result4 which is declared in above example, we are converting our integer values into Id type and successfully performing the required operations.

This is one of the use cases for Id monad. The other use cases will depend on our requirements and scenarios.

Eval Monad:

In Scala, we are familiar with three types of evaluations which are called eager, lazy and always.

Eager == val  // (compute during load)

lazy == lazy val  // (compute on demand)

always == def  // (compute always on demand)

In scala-cats we have evaluation monad called Eval which has all three equivalent properties of the eager, lazy and always evaluations. The example of Eval as below:

In the above example, we are creating Eval.now, Eval.later and Eval.always which is same as scala val, lazy val and def. According to the example, First, while our EvalExample1 class is loaded into memory, the eager is initialized and the message is printed and the value in eager block memorized. Second, while we call “value” on lazy eval, at that time, lazy eval prints the message and memorizes the value and the Third one, always eval, while we call “value” the message is printed but the value is not memorized that means every time when we call message will print.

Now the next Question that pops up is “In Scala, we have val, lazy val and def for memorizing and on-demand functionality, then why would we require Eval monad separately?”

Answer: The answer to this is quite simple. As we know, Eval is a monad, that means we have methods like map and flatMap for performing operations. In that case, whenever we need to perform some operation on our values in a composable manner, we are going to use Eval monad. Let’s take an example:

In the above example, We need to declare some eager value and after that, we need to perform the twice operation on that value and the results are going to divide by 2.

Without Eval monad, we need to perform these simple business requirements with the imperative style which makes our code contain more boilerplate and these operations are performed on a load of EvalExample2 class into memory. But Eval monad provides us a more composable and functional way of performing our operations on the value which are always lazy. In other words, Eval operations are only performed when we demand the value otherwise not.

As in the example output, without eval monad, our operations are performed during the load example into memory. But eval operations are only performed when we call “value” on it. In such a scenario, we will have a requirement of Eval monad. As mentioned earlier, the other scenarios depend on your requirements and business logic.

In our further blogs, we will try to explore some of the other monads which are provided by scala-cats.

References:

1. Scala With Cats By Noel Welsh and Dave Gurnel.