Last time we talked about the state Monad and we how solved this problem using type lambda.

I am sorry to say I did it again, following a strange path. During one of my morning fitness session I have been watching Rúnar Bjarnason presentation about Scalaz functional programming in Scala. As I am progressively understanding new concepts in Scala, I can now start getting interested in a small selection of libraries.

In my humble opinion, this is the way things should work: before using any dependency, one should get sure he understands (more than) the basic bricks of theory and potential applications at the origin of the creation of the library.

Getting my hands into Functors, Monads, Applicative Functors and their application can now open the door to a (small) range of selected libraries (not frameworks of course). Scalaz comes as a natural selection to be used... soon.

Naturally, before I have to understand a little bit more. Rambling in search of a concept implementation, derived from the talk, I realized I never took the time to write a Monad "concept" - in the concept pattern parlance - targeting functions.

Approaching functions as Functors, Monads and Applicative Functors demands a lot of effort to a lot of people (including me). But I would not say that creating the Monad implementation for function gets as harder as working with State Monads, I have to come back to on a regular base. And guess what, my understanding progresses each time.

The starting question we should ask - from my point of view - is : if we assume a Monad to manage a context for embedded values, what kind of context a function can be ? Looking at the type of a function, one can consider the

*returned result*as the embedded value extracted from a*context*being the*input value*. Then, what would a map function on a such a context look like:
In school we learnt very early a way to manage this kind of mapping between functions, thanks to function composition:

In the final version I just took benefit from the contravariance in the type definition of the applied transforming function

*f*. An alternate version could be:
So far, so good.

From the previous posts, and while playing with our project located here, we agreed on the following definitions for both Monads and Functors:

With a simple

*map*implementation for Functors, and having provided a generic*flatMap*definition, the only implementations we should worry about are both the*apply*and*flatten*method:
The easiest one, the

*apply*function, embeds an input value in a function context. This fresh context should be able to restore the value any time. A sort of*constant*function.
Regarding the

*flatten*method, typically what we expect is to*flatten*a function producing a function (*(A) ⇒ (A) ⇒ T*seen as*(A) ⇒ ((A) ⇒ T)*) to a function producing a simple value. That is exactly the purpose of the new function we created, applying successively the possible input*x*value to each of the function argument.
Armed with our implementations we now can derive a full

*Applicative Functor*implementation. As for the*State Monad*pattern, the*Applicative Functor*implementation accepts a single type parameter*Applicative[M[_]]*.
The type of functions we are working with are double parameter type constructor . In our working context, the type of returned values is the the embedded type in our Monad definitions. The function input parameter type defines a context from within the embedded type is extracted, therefore we must freeze the input type somehow. This is when type lambda comes into the place:

We freeze the function input type

*A*while the type*lambda projection*(through #) allows us to set a single parameter container to our Applicative Functor definition. But what's the use ?*The Learn You a Haskell*canonical example remains very simple:
We basically defines two operations accepting an input parameter each, and return the result of the combined functions. The more interesting part being that each function

**reads from the same input source**. I guess that's why we call the pattern the "Reader" Monad.
How many times did we encounter this situation when we had to apply different operations onto an input context from which we aimed to extract, then process values ?

The most recent example that came to my mind was setting up an environment from accessible configuration information. In his book, Joshua Suereth explains how to produce then combine optional

*Config*instances while building an application. Starting from there and using our new pattern just see how we can simulate the whole scenario:In our scenario we build some environment using connection, datastore, and application configuration. The configuration (aka

*Config*case class) is a container manageable using an implicit Applicative Functor.

the

*configBuilder*method implements a complete environment setup process. We use our Reader Monad implementation in order to extract from a unique source

- a connection configuration
- a datastore configuration from the connection configuration
- application configuration

*Map*here). The environment is set using the sugar syntax we defined around Applicative functors in a previous post.

Now, we know how to separate the concern of

*what we create from a*from**single source***how to process it*. Although the example remains simplistic, we have in our every day life as programmers, opportunities to clutter the code while applying different processes to a same immutable input (input analysis, input validation, information display etc.). The Reader Monad can save the day gathering in the same comprehension the whole process.
Code can be found here.

That's all folks. Not a big one this time. I need to do some Clojure too.

Be seeing you !!! :)

Be seeing you !!! :)

## 0 comments:

## Post a Comment