Background

Monad is an advanced concept of functional programming.

Monads are prevalent in Haskell because it only allows pure functions, that is functions that do not have side effects.

Pure functions accept input as arguments and emit output as return values, and that’s it.

In usual languages like Ruby, JavaScript or even Clojure, we do not have this constraint, but it often turns out to be a useful discipline to enforce yourself.

The typical monad introduction will tell you that monads are all about sneaking side effects into this model so you can do I/O.

But that’s just one application. Monads are really about composing functions, as we’ll see.

This article is not easy, but if you make the effor and go through it until the end, you’ll feel like you have climbed a mountain…

Our hope is that the the interactive code snippets of this blog post will help you to climb the mountain.

All the code snippets of this page are live and interactive powered by the KLIPSE plugin:

1. Live: The code is executed in your browser
2. Interactive: You can modify the code and it is evaluated as you type

It will work only if your browser supports EcmaScript6 arrow functions.

Logging function calls

Let’s imagine you have a function for finding the sine of a number, which in JavaScript would be a simple wrapper around the Math library:

var sine = (x) => Math.sin(x);
sine(0.123)

And you have another function for taking the cube of a number:

cube = (x) => x * x * x;
cube(0.987)

These functions take one number as input and return one number as output, making them composable: you can use the output of one as the input to the next:

sineCubed = (x) => cube(sine(x));
sineCubed(1.22);

Let’s create a function to encapsulate function composition. This takes two functions f and g and returns another function that computes f(g(x)).

compose = (f, g) => (x) => f(g(x)); 
var sineOfCube = compose(cube, sine);

var x = 1.22;
sineOfCube(x) === sineCubed(x);

Now, we decide that we need to debug these functions, and we want to log the fact that they have been called. We might do this like so:

var cube = (x) => {
  console.log('cube was called.');
  return x * x * x;
};

Pure functions - no side effects

But we’re not allowed to do this in a system that only allows pure functions: console.log() is neither an argument nor a return value of the function, it is a side effect.

If we want to capture this logging information, it must form part of the return value. Let’s modify our functions to return a pair of values: the result, and some debugging information:

var sine = (x) => [Math.sin(x), 'sine was called.'];
sine(0.3218)

var cube = (x) =>  [x * x * x, 'cube was called.'];
cube(3)

But we now find, to our horror, that these functions don’t compose:

compose(sine, cube)(3)

This is broken in two ways:

1. sine is trying to calculate the sine of an array, which results in null

2. we’re losing the debugging information from the call to cube

We’d expect the composition of these functions to return the sine of the cube of x, and a string stating that both cube and sine were called:

A simple composition won’t work here because the return type of cube (an array) is not the same as the argument type to sine (a number).

A little more glue is required. We could write a function to compose these ‘debuggable’ functions: it would break up the return values of each function and stitch them back together in a meaningful way:

var composeDebuggable = (f, g) => (x) => {
        const [y,s] = g(x),
               [z,t ] = f(y);
                   return [z, s + t];
};
composeDebuggable(sine, cube)(3)

We’ve composed two functions that take a number and return a (number, string) pair, and created another function with the same signature, meaning it can be composed further with other debuggable functions.

Haskell to the rescue

To simplify things, let’s borrow some Haskell notation. The following type signature says that the function cube accepts a number and returns a tuple containing a number and a string:

cube :: Number -> (Number,String)

This is the signature that all our debuggable functions and their compositions have. Our original functions had the simpler signature Number -> Number.

The symmetry of the argument and return types is what makes these functions composable. Rather than writing customized composition logic for our debuggable functions, what if we could simply convert them such that their signature was:

cube :: (Number,String) -> (Number,String)

We could then use our original compose function for glueing them together. We could do this conversion by hand, and rewrite the source for cube and sine to accept (Number,String) instead of just Number but this doesn’t scale, and you end up writing the same boilerplate in all your functions.

The Writer monad

Far better to let each function just do its job, and provide one tool to coerce the functions into the desired format. We’ll call this tool bind, and its job is to take a Number -> (Number,String) function and return a (Number,String) -> (Number,String) function.

Let’s write bind in javascript:

var bind = (f) => function(tuple) {
      const [x, s] = tuple,
              [y, t] = f(x);
                return [y, s + t];
};

We can use this to convert our functions to have composable signatures, and then compose the results.

var f = compose(bind(sine), bind(cube));
f([3, ''])

But now all the functions we’re working with take (Number,String) as their argument, and we’d much rather just pass a Number.

As well as converting functions, we need a way of converting values to acceptable types, that is we need the following function:

unit :: Number -> (Number,String)

The role of unit is to take a value and wrap it in a basic container that the functions we’re working with can consume. For our debuggable functions, this just means pairing the number with a blank string:

var unit = (x) => [x, ''];

var f = compose(bind(sine), bind(cube));
f(unit(3)) 

Or, we can also compose f and unit, like this:

compose(f, unit)(3) 

This unit function also lets us convert any function into a debuggable one, by converting its return value into an acceptable input for debuggable functions. For instance:

// round :: Number -> Number
var round = function(x) { return Math.round(x) };

// roundDebug :: Number -> (Number,String)
var roundDebug = function(x) { return unit(round(x)) };
roundDebug(1.23)

Again, this type of conversion, from a ‘plain’ function to a debuggable one, can be abstracted into a function we’ll call lift.

lift :: (Number -> Number) -> (Number -> (Number,String))

The type signature says that lift takes a function with signature Number -> Number and returns a function with signature Number -> (Number,String).

And now, the code for lift:

var lift = (f) => compose(unit, f);

Let’s try this out with our existing functions and see if it works:

var roundDebug = lift(Math.round);

var f = compose(bind(roundDebug), bind(sine));
f(unit(27)) // -> [1, 'sine was called.']

Summary

We’ve discovered three important abstractions for glueing debuggable functions together:

1. lift - which converts a ‘simple’ function into a debuggable function
2. bind - which converts a debuggable function into a composable form
3. unit - which converts a simple value into the format required for debugging, by placing it in a container

These abstractions (well, really just bind and unit), define a monad. In the Haskell standard library it’s called the Writer monad.

PS: This article is a rewrite of Translation from Haskell to JavaScript of selected portions of the best introduction to monads I’ve ever read with interactive code snippets instead of static ones.

PPS: If you are a technical blogger, feel free to write interactive code snippets with the KLIPSE plugin…