A year ago I started my journey in Scala. It’s just a nicer Java they said. But there is this camp of people who wanted to use Scala for functional programming. In order to truly understand that idea, one must understand its philosophy.

Delay as much as possible

The ideal program in a functional paradigm is to describe what should happen and then only executing it at the very end.

Composition is key

Suppose we have a function f: A => B and another g: B => C, high school maths reminds us that we can compose them to get a function g o f : A => C (ignoring the domain constraints). Hence rather than writing

def lengthOfEvenNumber(a: List[Int]): Int = {
    val x = a.filter(_ % 2 == 0)
    val y = x.size
    y
}

It is preferable to write

def length of EvenNumberF(a: List[Int]): Int = filter(_ % 2 == 0) >> (_.size)

Note: » is just the syntax for flatmap.

How far can one push composition?

What if f: A => M[B] and g: B => M[C] where M is some “container” (think of M as a List for example). Can we still compose f and g in some manner?

That’s where Kleisli comes in. It is a datastructure that’s “describing” such functions the same way as IO is a datastructure that “describes” the unsafe work to be done [to the real world].

Think of Kleisli[M ,A, B] as representing a function of type A => M[B]

By wrapping f and g with Kleisli, we can now do composition as follows:

val p = Kleisli[M, A, B] (f)
val q = Kleisli[M, B, C] (g)
val r: Kleisli[M, A, C] = p >> q

What are the trade offs here?

On the plus side, we are now able to compose functions that returns a container.

However, this comes at a cost of learning the semantics and motivation of such datastructures. It took me several occasions to grasp this idea and the myraid of academic topic in the domain of category theory does not help keep the research on track.