# ...And Monads for (Almost) All: The Reader Monad

`design`

`programming`

`fp`

Who follows me from the beginning perfectly knows my obsession for the dependency management in programming languages. I have already written of dependency injection mechanisms in modern programming languages. In Eat that cake! I wrote about the Cake Pattern and how to use Scala self types to resolve the problem of dependency injection. In Resolving your problems with Dependency Injection, I introduced the problem of the dependency resolution. In Resolve me, Implicitly, I showed how to use Scala `implicit`

s to implement a dependency injection mechanism. Now its time to speak about how functional programming tries to solve the dependency management issue, using the *Reader Monad*.

## The problem

Imagine you have a type whose responsibility is to manage the persistence of *stocks* information. Let we call it `StockRepository`

. The repository can retrieve all the stocks present in a wallet, can sell a quantity of a stock or can buy some amount of stock. It follows the definition of such a type.

The repository implements what we can call *persistence logic*.

Then, we have a type that uses the `StockRepository`

to give to its clients some *business logic* built upon the above *persistence logic*. Let’s call it `Stocks`

. Imagine that we want to give access to the three functions of the repository, plus a fourth function that invest money in the stock that has the lowest quotation.

`findAll()`

`sell(stock: String, quantity: Double)`

`buy(stock: String, amount: Double)`

`investInStockWithMinValue(amount: Double)`

So, `Stocks`

has a dependency upon `StockRepository`

. How can we express such fact in the code? We don’t want to use the *constructor injection* mechanism or anything related to it. We want to stay *functional*.

## Dependency management within functions

### The trivial solution

An option is to pass a reference of the repository to each function that need to access to its methods.

This trick does its dirty job, but it pollutes the signature of each function that needs some external dependency. Our example has only one dependency, but in real life, dependencies are often more than one.

### Using currying to isolate dependencies

The *currying* process can help us to make things a little better. Imagine isolating the dependency parameters using a curried version of the previous functions.

As you know, the currying process allows us to *partially applied* a function, obtaining as the result of the partial application a new function with fewer inputs.

In mathematics and computer science, currying is the technique of translating the evaluation of a function that takes multiple arguments into evaluating a sequence of functions, each with a single argument.

Let’s take an example.

Let the function `def add(a: Int, b: Int): Int = a + b`

that adds to integers. If we apply currying to the function `add`

we obtain the following new function.

The return type of the function `add`

is not anymore a pure `Int`

but now it is a function from `Int => Int`

.

If we apply the currying reasoning to the functions of the `Stocks`

module, we obtain the following definition.

We remove the ugly `StockRepository`

parameter from the signature of our function! Yuppi yuppi ya! However, it is complicated to compose functions with the last signature we had :( Imagine that we want to implement the function `investInStockWithMinValue`

using the function we developed so far. A possible implementation is the following.

It is not simple to follow what is going on. The use of the function `andThen`

does not help the reader to understand the main workflow of the function, because it is not semantically focused on the operation it is carrying on. Moreover, in the last line, there is a very ugly function application, `Stocks.buy(s, amount)(repo)`

that waste our code with a detail that is not related to the business logic but only to the implementation.

We can do better than this. Much better.

## The Reader monad

What if we encapsulate the curried function inside a data structure? Using such an approach is precisely the idea behind the *Reader Monad*.

We have our function, let’s say `f: From => To`

, where `From`

and `To`

are respectively the starting type (domain) and the arriving type (codomain) of the function. As we just said, we put a data structure around our function.

We want to apply in some way the function enclosed inside our data structure. We add the application function.

To improve the readability of our code, we want to have a function different from `andThen`

to compose a function `f`

. Given a function `g: To => NewTo`

, we need a function to compose `g`

with `f`

inside a `Reader`

. This function is called `map`

.

The `flatMap`

function composes `f`

with functions `z: To => Reader[From, NewTo]`

. This function is equal to the last application of the `andThen`

method in our previous example.

In other words, the `flatMap`

function serves to compose two functions sharing the same dependency. In our example, using a `flatMap`

, we can compose the functions `findAll`

and `buy`

both sharing the dependency among a `StockRepository`

. Using a simple `map`

, we would obtain the nesting of a `Reader`

into another `Reader`

.

Quite annoying. Using a `flatMap`

, instead, we can *flatten* the result type, and everything goes ok. The function application in the `flatMap`

definition does the trick.

Finally, we need an action to *lift* a value of type `To`

in a `Reader[From, To]`

. In other words, we want to be able to create from a value of type `To`

a function that receives a value of type `From`

and returns a value of type `To`

. This function is not a member of the `Reader`

monad itself. It is more like a *factory method*.

The whole `Reader`

type is something similar to the following.

It happens that the type `Reader`

satisfies with its functions `apply`

, `map`

and `flatMap`

the minimum properties needed to be a *monad*. The description of the *monad laws* is behind the scope of this post.

Moreover, because of the presence of the function `map`

and `flatMap`

, we can use the type `Reader`

in a fashion way to simplify our code.

## Finally, using the monad

First of all, we change the `Stocks`

type with the `Reader`

monad.

As you can see, every direct dependency was removed and substituted with the `Reader[StockRepository, _]`

type.
Now, it’s time to return to our previous `investInStockWithMinValue`

function. Using the methods we defined on the monad, we can rewrite the function as follows.

Using the syntactic sugar available from the Scala language, we can rewrite the above code use a *for-comprehension* statement.

I love the *for-comprehension* construct because it is self-explanatory :)

Who is responsible for resolving the dependencies, declared through the `Reader`

monad? The answer is simple, that is the `main`

method.

### What if I have more than one dependency?

Very often, we have functions that depend by more than one single dependency. For example, think that you want to add a rate change service to the functions of the `Stock`

type. Using `RateChangeService`

, it is possible to buy and sell in a currency that is different from dollars.

The Reader monad we just analyzed handles only one dependency at time. Should we try away all the suitable types we developed until now? No, we shouldn’t. If you depend on more than one type, you can create a new container type, something similar to a *context*.

In this way, we reduce our function to depend on a single type again, our `Context`

type. Ball, game, set.

## Conclusions

In this post, we analyzed how to declare dependencies in functions. We begin from the simplest possible solution, and we composed step by step a more elegant and practice solution that is called the `Reader`

monad. Finally, we showed how the monad could simplify the code through the use of the *for-comprehension* construct.

The code of the `Reader`

monad is available on my GitHub, reader-monad. I also developed a version of the monad in Kotlin, for the lovers of this emergent programming language, reader-monad-kotlin.