Advanced FP for the Enterprise Bee: Kleisli

An (Non-Kleisli) Arrow Pointing to Honey

Introduction

This is the fourth article in a series, exploring advanced FP concepts for practically minded Kotlin developers. So far we have looked at Traverse, Applicatives and Higher Kinded Types. This time we are investigating the Kleisli type.

I was very reluctant to go near this concept, mostly because this term is borrowed from Category Theory. So I assumed it would be tortuous. Fortunately it turns out Kleisli is simpler than a lot of the concepts we have already covered.

A Sample Problem

Let’s start by revisiting an only friend from our first article. This function attempts to read a JVM property, returning the result in an Either.

Let’s imagine we need to navigate a chain of property values:

• We are given the key A for a JVM property
• The value of property A will be the key B
• The value of property B will be the key C
• This process must be repeated N times

Let’s create two helper methods, one to create such a chain and the other to print out all the JVM properties:

As sample data let’s use the lineage of House Atreides from the Dune books:

When we run the above the output contains the following information:

            Vladimir | Jessica
             Jessica | Paul
                Paul | Ghanima
             Ghanima | Moneo
               Moneo | Siona

Our task is to navigate this chain of associations via FP and Arrow.

A Procedural Solution

This is how the problem could be solved in a procedural way:

Running this code produces the correct output:

Right(Siona)

There are three problems with the procedural approach:

• We had to wrap up propertyViaJVM in a new function that takes an Either
• To implement this function we need to be mindful of the rules for Either
• Applying this function requires nesting and/or temporary variables

The Kleisli Solution

Here’s the solution written using the Kleisli type. We still wrap up the propertyViaJVM function, but there are important differences:

• The wrapping is performed for us via Kleisli { … }
• The wrapped function takes a regular String as input
• The implementation of Either is abstracted from us

We chain together all the required calls using andThen. This composes the calls together into a single sequence, which is executed when we call run. A call to fix is required to perform a downcast, for reasons discussed in the previous article.

If you’re familiar with the CompletableFuture type in the Java threading libraries this is a very similar design. Let’s see how it performs with correct and erroneous data:

It gives us precisely what we want:

Right(Siona)
Left(No JVM property: Alia)

Because we are only wrapping up a single function, we can simplify the code by replacing the lambda with a method reference:

Additional Functionality in Kleisli

So far we have seen that the Kleisli type simplifies the composition of functions, where the functions return, but do not accept, a monadic type like Either or Validated. There are also some helpful utility methods. Let’s modify our input data slightly:

In addition to the existing requirements we now want to:

• Append ‘Harkonnen’ to the initial value given by the client. This ability is provided by the local function.
• Append ‘Atreides’ to the final value produced by the call to run. As you might expect, this ability is provided by the map function.

Once again this gives us the output we wanted:

Right(Siona Atreides)
Left(No JVM property: Alia)

Why Not Use Monads?

When I encountered Kleisli my immediate question was ‘why not just use Monadic Composition?’. It turns out that we always can — and in fact that’s how the Kleisli is implemented.

You may have noticed above that we passed the Either Monad into andThen. Turns out that, if you have already implemented a monadic type, then you get the Kelisli for free. So you can choose whichever approach suits best.

Here’s the problem solved using Monadic Composition directly:

This gives the result we want. But compared to the Kleisli solution there is a lot more ‘plumbing’. We had to remember to:

• Make our functions suspending
• Use the bang operator (or equivalent)
• Declare variables for intermediate results

What Are Kleisli Arrows?

In both Pure Functional Programming and Category Theory the composition of functions is represented by drawing (or coding) arrows. Here’s a superb talk, filled with arrow diagrams, by Philip Wadler. A Kleisli Arrow represents functional composition within a monadic context. In our case the monad was Either, but it could have been Validated, Writer, State etc...

This is why functional libraries, language permitting, often provide an arrow symbol as an alternative to the andThen method. Here’s our example rewritten in Scala and the Scalaz library.

Note how, on line 31, we use the >=> operator to combine the functions:

Conclusions

Despite the term Kleisli originating from Category Theory, it is neither complex nor impractical. Kleisli is a great alternative to Monadic Composition any time you have:

• One or more functions that return a Container (aka. Monad) but take regular parameters.
• A requirement to chain these functions together to obtain a final result.

Running The Sample Code

As usual all the code listed can be found in this BitBucket repo. However the Kleisli type used is still experimental and hence can be found in the Arrow Incubator Project. To run my ‘UsingKleisli’ project you will have to first clone and build arrow-incubator, and then copy the arrow-mtl and arrow-mtl-data libraries into the libs folder.

Thanks

I am grateful to Richard Gibson and the Instil training team for reviews, comments and encouragement on this series of articles. All errors are of course my own.