**Gist**: the state monad allows to chain (i.e. to execute in sequence) a wide sort of operations, each one returning one single parameter called “value”. A second parameter called “state” is passed through the chain of the operations, acting as a representation of the evolving state of the system throughout the various steps. A JS implementation of the state monad is presented here. The state monad appears to be very well capable of handling I/O operations. A simple GUI composed by prompt (returning as value the user input) and alert (returning as value undefined) is put at work with interesting results. All this in the comfort of your favorite browser.

Thinking about the state monad implementations given in [1] and [2] I have come to define a chainable state monad of my own liking. Going through the superb “Monads are Elephants – part 4” ([3]) and looking from a close distance the working of a Scala I/O monad I came to realize that the state monad in my hands should be able to perform those I/O operations as well. For those who are acquainted with the latter post, it will be clear that this – obviously typeless – monad of mine does not handle the state of the system, let alone the state of the world, with the care deemed necessary by the author of that article.

Once more, the monad I present is based on the command module ([4]). Its code is organized in the following manner:

```
var myStateMonad = function() {
var monad, unit, bind, flatten, map, lift, filter,
fail, executor, onError, instanceOf
;
…
… code …
…
return {
// static methods
monad: monad,
unit: unit,
lift: lift,
liftM: lift
};
}();
Monad.state = myStateMonad;
```

Likewise the maybe monad of the previous article, it is possibly overkill to export all the methods. Actually I see that so far I’ve been using only monad, unit, filter and onError. The other ones are invoked by the monad itself.

**WHAT ABOUT Function.prototype.bind?**: The process described in this page produces a monad, a JS function, which has its own *prototype.bind* method overridden. That’s a bad idea for production code. But I really dislike the name *flatMap*, so I won’t use it in this experiment.

The most important method in the previous API is *monad*. And what is that? It’s actually a data constructor.

### A state monad is *a function*

The state monad is basically a function that takes a state and returns a pair (state,value). Using Haskell syntax, its type is:

`s -> (s,a)`

Once available, a state monad should be callable through a simple invocation `monad(state) `

and yet, almost any language forces to invoke it through an accessor method called `runState`

, `s2scp `

(state to state-content pair) and the likes. This is awkward: this monad is a function, it’s not a “container” like the maybes or the lists. Forcing me to treat it as an ‘object’ is unnatural.

I understand this must be done in Java or Scala, but discovering I have to do it also in Haskell (even though there are a few subtle differences in the matter) was kinda disappointing.

Here JavaScript shines once more. In JavaScript we can build the state monad as a function and pass it a state as its natural only argument.

In JavaScript we can shape the monad as a JS function and decorate *that* function with `bind`

and the other accessory methods. We don’t even have to attach them to the monad prototype (go ahead if you like, but to me that’s a pointless complication).

That’s the job of the static method `Monad.state.monad`

; this method receives a plain JS function `s -> (s,a)`

, which I’ll call `fssa`

, and transforms it in a state monad. Please refer to the geiesmonads_2.0.js file.

```
var monad = function(fssa) {
// clone using its prototype.bind
var result = fssa.bind({});
result.bind = bind;
result.flatten = flatten;
result.map = map;
result.filter = filter;
result.iff = iff;
result.onError = onError;
result.instanceOf = instanceOf;
return result;
}
```

The other building block is *unit* (aka *return*); as its nature commands, unit wraps a user value and allows to access that value anytime *within the monad context* by providing a state.

```
var unit = function(value) {
var fssa = function(state) {
return {state:state, value:value};
}
return monad(fssa);
}
```

The product of both monad and unit is first and foremost a *JS function*. A function enriched with methods to allow the chaining of calls.

The most important thing to give the monad is, as usual, *bind *(aka *flatMap*). This is how bind is defined inside the module at the top of this post:

```
var bind = function (famb) { // famb : a -> m b
var that = this;
return monad(function(state) {
// cp = current pair
var cp = that(state);
return famb(cp.value)(cp.state);
});
}
```

At the heart of the code you may recognize the steps that realize the sequential execution flow of the two bound operations. Those lines will execute when an external state will be applied. We are inside the current monad (let’s call it A) and we refer to it as *that *because of the famous JS quirk:

- A (i.e. the first operation) executes:
`that(state)`

returns an object`{state:A_STATE,value:A_VALUE}`

which we name`cp`

(current pair) - the monad B resulting from the binding is the product of the application of the function
`famb`

to`cp.value`

; monad B is therefore`famb(cp.value)`

- the state that this monad will have to receive is
**not the original one provided to A**, because A could have modified it!!; the state for B gotta be the one produced by the resolution of A, and that’s`cp.state`

; therefore we use that state to resolve the B monad:`famb(cp.value)(cp.state)`

- this convoluted application of state altogether defines a function
`s -> (s,b)`

. We gotta return a monad instance and therefore we pass the function to the monad constructor

The rest of this post is dedicated to the presentation of a simple GUI featuring flow control, with the state monad actually acting as I/O monad. A further post presents heavier applications of the state monad.

### A very simple GUI: prompt and alert

With the state monad in our hands we can start doing some interesting experiments, still under the guide and inspiration of [3].

First of all, we need one input and one output function:

```
var getString = function(value) {
return Monad.state.unit(prompt(value));
};
var putString = function(value) {
return Monad.state.unit(alert(value));
};
```

Please note that `getString`

and `putString`

are **not** state monads. But once they are given a value, we have two simple, nice state monads in our hands to work with.

`getString`

and `putString`

are actually what I called `famb`

while explaining `bind`

. Why `famb`

? Because it’s a shortcut for *function from a to monad b*. Famb’s are the standard argument for

`bind`

. In the present situation, these two functions take a value and wrap it with a plain state monad.`getString`

needs to be told (possibly from a preceding monad or directly from the programmer) what value to show in the `prompt`

popup. The value `getString`

passes down the chain is instead the return value of `prompt()`

, i.e. the string containing the user input.

`putString`

needs to be told (possibly from a preceding `getString`

or directly from the programmer) what value to show in the `alert`

popup. The value `putString`

passes down the chain is instead the return value of `alert()`

, i.e. `undefined`

. No big deal.

Wrapping `prompt`

and `alert`

with unit will entail that no actions are performed by these monads to the input state (check the code of `unit`

about this point). It doesn’t have to be this way; we could do something to the state, but we don’t have to. Actually, here what we really care about are the side effects of these calls: we need the popups to interact with the user!

If JavaScript were Scala, we would put our two monads at work in a for-comprehension like:

```
for {
name <- getString('what is your name?');
x <- putString('welcome ' + name); // we know x will be undefined, so what?
} yield … // whatever gets yielded, we don’t care…
```

…and it would be (almost) crystal clear what we want our little program to do. But for-comps in JS aren’t available so we must perform one further step. We do this keeping in mind the relationship between for-comps, `map`

and `bind`

(aka `flatMap`

) [4].

The previous for-comprehension becomes:

```
getString('what is your name?')
.flatMap(name -> putString('welcome ' + name) // flatMap === bind
.map(x -> WHATEVER)
)
```

In other words, if we want to chain `putString`

after the state monad `getString('what is your name?')`

, we must wrap it with a lambda(`value`

) in order to make it palatable to `bind`

. The result is then:

```
var promptThenGreet = getString('what is your name?')})
.bind(function(name){ return putString('welcome ' + name);});
promptThenGreet(0); // whatever state
```

This produces two popups in sequence. The name you insert in the first comes back welcomed in the second popup.

**A LITTLE CAVEAT**: whatch out for `getString`

: since we need its value first thing to feed it to unit, it fires the popup immediately at the moment of *definition* of the monad `promptThenGreet`

, without waiting for the state to be provided at runtime (that’s to say at the following line). Because the other operations in the chain wait patiently their turn and fire only once the state is provided, the workaround is to put in front of the first `getString`

a dumb fixed-point state monad which I called `start`

.

```
var start = Monad.state.monad(function(state) {
return {state : state, value : 'whatever'};
});
var promptThenGreet2 = start
.bind(function(_) { return getString('what is your name?'); })
.bind(function(name) { return putString('welcome ' + name); });
promptThenGreet2(0); // whatever state
```

This guarantees that the first popup will appear only during the run with the state.

#### So far, this state monad has done nothing with state

I reckon what I have shown here is just a couple of examples of an I/O monad. There is not really an evolving state in these examples. Those examples are provided in a following post.

Having said that, we can complete the talk about I/O and show how a state monad can handle errors.

### Filtering values and managing the execution flow

Still following the Scala example from [3], we create a filter:

```
// predicate: value -> boolean
function filter(predicate, msg) {
function _iff(value) {
if (predicate(value)) {
return unit(value);
} else {
return fail(msg + '-' + value);
}
};
return this.bind(_iff);
};
```

Then we create a failing `a -> mb`

function:

```
function fail(value) {
return monad(function(state) { throw {message : value}; });
};
```

Let’s spend one minute here: this code will become part of the public state monad API. This function is gonna become a method attached to the main monad `s -> (s,a)`

function. Therefore, inside filter `this`

is the chainable monad itself.

What is `_iff`

, then? `_iff`

is a function that takes a value and returns:

- a plain state monad that forwards the value, when the value satisfies the predicate
- a failing state monad that carries information about the filter failure, when not

Therefore, `_iff`

is an `a -> mb`

function, which may be bound without trouble. By returning `this.bind(_iff)`

from filter we just add one more ring to the chain and get ready to go on.

If `_iff`

says yes and returns `unit(value)`

, when we run the monad the ring will pass the state on. Problem is: if `_iff`

returns `fail('msg - boom!')`

instead, we’ve put inside our chain a ring that will explode no matter what.

In other words:

```
getString(‘who are you?’)
.filter(function(name) {
return (name != ‘Jeremy’);
}, ’Not welcome’);
```

is the monad resulting by binding the outcome of the run of the filter predicate to the initial `getString`

monad. That’s a state monad that will throw an exception whenever any clueless Jeremy provides his name at the prompt. Hmmm, isn’t this too extreme? We may use an `onError`

handling monad:

```
function onError(errorHandler) {
var that = this;
return function(state) {
try {
return that(state);
} catch (exception) {
return errorHandler(exception)(state);
}
};
};
```

Binding all this somewhere down the chain will guarantee that, wherever in the previous computation an exception is thrown, the provided `errorHandler`

will take care of the graceful resolution of the problem.

The `errorHandler`

can better be itself a state monad, so to be able to keep chaining behavior afterwards. The handler will handle the exception as its own input value, possibly taking the state (which has been neatly forwarded by `onError`

) into account; in our example the handler ain’t that smart and just alerts Jeremy that he’s not welcome and therefore must go away.

```
var showTheDoor = function(exc) {
return putString('go away-' + exc.message);
}
```

Tying it all together we have:

```
var promptThenCheckThenGreetOrElseShowTheDoor = start
.bind(function(_) { return getString('what is your name?\nNB - Jeremy is not welcome'); })
.filter(function(x) { return (x!='Jeremy'); }, 'not welcome')
.bind(function(y) { return putString('welcome ' + y); })
.onError(showTheDoor);
promptThenCheckThenGreetOrElseShowTheDoor(0);
```

Please note that we don’t need to wrap the whole computation inside a single closure to carry the user-entered value until the end of the flow:

- if the filter succeeds, the good value will be passed as
`y`

to`putString`

- if the filter fails, the bad value will reach
`onError`

through the`throw-catch`

mechanism

The next flow operator is `iff(predicate, trueMonad, falseMonad)`

; it chooses which monad to execute depending on a predicate check.

```
function iff(predicate, trueMonad, falseMonad) {
function _iff(value) {
if (predicate(value)) {
return trueMonad.bind(function(_){return unit(value)})
} else {
return falseMonad.bind(function(_){return unit(value)})
}
}
return this.bind(_iff);
}
```

### Why is all this bloody relevant?

What we have here is a very lightweight API (`unit`

, `bind`

, `filter`

, `iff`

, `onError`

) for describing a sequence of operations. The operations can be made complex at will, and they may even involve interactions with the user, the filesystem, an external db or the web.

The state of the execution is kept safely inside the running process, it may be updated at will at each step and the updated value is passed effortlessly to the next step in the execution chain. Like the operations, also the state can be made exceedingly complicated to suit the complexity of the operations. The thread of the operations would act as the controller/presenter/youNameIt, while the state would contain handles to the view.

The complete, final sequence is built from simpler components using a very small set of operations. Component monads can be further composed together, the way `showTheDoor`

took seat inside `onError`

. Probably we would need a couple more of handler monads in our toolbox to make repetitive things simpler (I haven’t yet spoken about `map`

, `lift`

and `flatten`

, but they’re there in the geiesmonads github repository, covered with tests and perfectly working). Then we’d need a GUI that allows drag and drop of the components into the final bound sequence.

If I were to make a bet I’d say that Scratch, the program that teaches programming to kids, must be using some kind of mechanism like this at its heart.

I can’t yet see with clarity the impact of recursion on all this. At the end of [3] we are warned that running the complete solution proposed there (a real-time continuous gatekeeper routine) causes sooner or later a stack overflow. And in the previous post I put some pointers that show the not quite efficient implementation of closures in JS engines. But ok, I can see anyway a lot of useful non-recursive applications for these concepts.

What I enjoy the most is that I’ve brought all these nice Haskell/OCaml/Scala concoctions into… plain JavaScript, the language that pays my bills at the end of the month. The road ahead is still long, but it looks feasible and promising.

As with OO design patterns (you don’t go to work saying to yourself “today I’m gonna do two Singletons and one AbstractFactory”), I reckon it’s necessary to let the state monad blend naturally and invisibly in the FP landscape; it’s necessary to reach a state where you write functions like these without needing their cheat sheet at hand.

Gotta keep studying. Every comment is welcome.

[1] http://igstan.ro/posts/2011-05-02-understanding-monads-with-javascript.html

[2] http://jabberwocky.eu/2012/11/02/monads-for-dummies/

[3] http://james-iry.blogspot.it/2007/11/monads-are-elephants-part-4.html

[4] http://www.yuiblog.com/blog/2007/06/12/module-pattern/

[5] http://stackoverflow.com/questions/12792595/how-to-convert-this-map-flatmap-into-a-for-comprehension-in-scala

Reblogged this on Sutoprise Avenue, A SutoCom Source.