Refactoring the Monadster

UPDATE: Slides and video from my talk on this topic

Warning! This post contains gruesome topics, strained analogies, discussion of monads

Welcome to the third installment in the gripping tale of Dr Frankenfunctor and the Monadster!

We saw in the first installment how Dr Frankenfunctor created life out of dead body parts using “Monadster part generators” (or “M"s for short), that would, on being supplied with some vital force, return a live body part.

We also saw how the leg and arms of the creature were created, and how these M-values could be processed and combined using mapM and map2M.

In the second installment we learned how the head, heart and body were built using other powerful techniques such as returnM, bindM and applyM.

In this last installment, we’ll review all the techniques used, refactor the code, and compare Dr Frankenfunctor’s techniques to the modern-day state monad.

Links for the complete series:

• Part 1 - Dr Frankenfunctor and the Monadster
• Part 2 - Completing the body
• Part 3 - Review and refactoring (this post)

Before we refactor, let’s review all the techniques we have used.

We couldn’t create an actual live body part until the vital force was available, yet we wanted to manipulate them, combine them, etc. before the lightning struck. We did this by creating a type M that wrapped a “become alive” function for each part. We could then think of M<BodyPart> as a recipe or instructions for creating a BodyPart when the time came.

The definition of M was:

type M<'a> = M of (VitalForce -> 'a * VitalForce)

Next, we wanted to transform the contents of an M without using any vital force. In our specific case, we wanted to turn a broken arm recipe (M<BrokenLeftArm>) into a unbroken arm recipe (M<LeftArm>). The solution was to implement a function mapM that took a normal function 'a -> 'b and turned it into a M<'a> -> M<'b> function.

The signature of mapM was:

val mapM : f:('a -> 'b) -> M<'a> -> M<'b>

We also wanted to combine two M-recipes to make a new one. In that particular case, it was combining an upper arm (M<UpperRightArm>) and lower arm (M<LowerRightArm>) into a whole arm (M<RightArm>). The solution was map2M.

The signature of map2M was:

val map2M : f:('a -> 'b -> 'c) -> M<'a> -> M<'b> -> M<'c>

Another challenge was to lift a normal value into the world of M-recipes directly, without using any vital force. In that particular case, it was turning a Skull into an M<Skull> so it could be used with map2M to make a whole head.

The signature of returnM was:

val returnM : 'a -> M<'a>

We created many functions that had a similar shape. They all take something as input and return a M-recipe as output. In other words, they have this signature:

val monadicFunction : 'a -> M<'b>

Here are some examples of actual monadic functions that we used:

val makeLiveLeftLeg : DeadLeftLeg -> M<LiveLeftLeg>
val makeLiveRightLowerArm : DeadRightLowerArm -> M<LiveRightLowerArm>
val makeLiveHeart : DeadHeart -> M<LiveHeart>
val makeBeatingHeart : LiveHeart -> M<BeatingHeart>
// and also
val returnM : 'a -> M<'a>

The functions up to now did not require access to the vital force. But then we found that we needed to chain two monadic functions together. In particular, we needed to chain the output of makeLiveHeart (with signature DeadHeart -> M<LiveHeart>) to the input of makeBeatingHeart (with signature LiveHeart -> M<BeatingHeart>). The solution was bindM, which transforms monadic functions of the form 'a -> M<'b> into functions in the M-world (M<'a> -> M<'b>) which could then be composed together.

The signature of bindM was:

val bindM : f:('a -> M<'b>) -> M<'a> -> M<'b>

Finally, we needed a way to combine a large number of M-parameters to make the live body. Rather than having to create special versions of map (map4M, map5M, map6M, etc), we implemented a generic applyM function that could apply an M-function to an M-parameter. From that, we could work with a function of any size, step by step, using partial application to apply one M-parameter at a time.

The signature of applyM was:

val applyM : M<('a -> 'b)> -> M<'a> -> M<'b>

Note that of all these functions, only bindM needed access to the vital force.

In fact, as we’ll see below, the functions mapM, map2M, and applyM can actually be defined in terms of bindM and returnM!

A lot of the functions we have created have a very similar shape, resulting in a lot of duplication. Here’s one example:

let makeLiveLeftLegM deadLeftLeg  =
    let becomeAlive vitalForce =
        let (DeadLeftLeg label) = deadLeftLeg
        let oneUnit, remainingVitalForce = getVitalForce vitalForce
        let liveLeftLeg = LiveLeftLeg (label,oneUnit)
        liveLeftLeg, remainingVitalForce
    M becomeAlive  // wrap the function in a single case union

In particular, there is a lot of explicit handling of the vital force.

In most functional languages, there is a way to hide this so that the code looks much cleaner.

In Haskell, developers use “do-notation”, in Scala people use “for-yield” (the “for comprehension”). And in F#, people use computation expressions.

To create a computation expression in F#, you just need two things to start with, a “bind” and a “return”, both of which we have.

Next, you define a class with specially named methods Bind and Return:

type MonsterBuilder()=
    member this.Return(x) = returnM x
    member this.Bind(xM,f) = bindM f xM

And finally, you create an instance of this class:

let monster = new MonsterBuilder()

When this is done, we have access to the special syntax monster {...}, just like async{...}, seq{...}, etc.

• The let! x = xM syntax requires that the right side is an M-type, say M<X>.
  let! unwraps the M<X> into an X and binds it to the left side – “x” in this case.
• The return y syntax requires that return value is a “normal” type, Y say.
  return wraps it into a M<Y> (using returnM) and returns it as the overall value of the monster expression.

So some example code would look like this:

monster {
    let! x = xM  // unwrap an M<X> into an X and bind to "x"
    return y     // wrap a Y and return an M<Y>
    }

If you want more on computation expressions, I have an in-depth series of posts about them.

With monster expressions available, let’s rewrite mapM and the other functions.

mapM

mapM takes a function and a wrapped M-value and returns the function applied to the inner value.

Here is an implementation using monster:

let mapM f xM =
    monster {
        let! x = xM  // unwrap the M<X>
        return f x   // return M of (f x)
        }

If we compile this implementation, we get the same signature as the previous implementation:

val mapM : f:('a -> 'b) -> M<'a> -> M<'b>

map2M

map2M takes a function and two wrapped M-values and returns the function applied to both the values.

It’s also easy to write using monster expressions:

let map2M f xM yM =
    monster {
        let! x = xM  // unwrap M<X>
        let! y = yM  // unwrap M<Y>
        return f x y // return M of (f x y)
        }

If we compile this implementation, we again get the same signature as the previous implementation:

val map2M : f:('a -> 'b -> 'c) -> M<'a> -> M<'b> -> M<'c>

applyM

applyM takes a wrapped function and a wrapped value and returns the function applied to the value.

Again, it’s trivial to write using monster expressions:

let applyM fM xM =
    monster {
        let! f = fM  // unwrap M<F>
        let! x = xM  // unwrap M<X>
        return f x   // return M of (f x)
        }

And the signature is as expected

val applyM : M<('a -> 'b)> -> M<'a> -> M<'b>

We’d like to use the monster expression to rewrite all our other functions too, but there is a stumbling block.

Many of our functions have a body that looks like this:

// extract a unit of vital force from the context
let oneUnit, remainingVitalForce = getVitalForce vitalForce

// do something

// return value and remaining vital force
liveBodyPart, remainingVitalForce

In other words, we’re getting some of the vital force and then putting a new vital force to be used for the next step.

We are familiar with “getters” and “setters” in object-oriented programming, so let’s see if we can write similar ones that will work in the monster context.

Let’s start with the getter. How should we implement it?

Well, the vital force is only available in the context of becoming alive, so the function must follow the familiar template:

let getM =
    let doSomethingWhileLive vitalForce =
        // what here ??
        what to return??, vitalForce
    M doSomethingWhileLive

Note that getting the vitalForce doesn’t use any up, so the original amount can be returned untouched.

But what should happen in the middle? And what should be returned as the first element of the tuple?

The answer is simple: just return the vital force itself!

let getM =
    let doSomethingWhileLive vitalForce =
        // return the current vital force in the first element of the tuple
        vitalForce, vitalForce
    M doSomethingWhileLive

getM is a M<VitalForce> value, which means that we can unwrap it inside a monster expression like this:

monster {
    let! vitalForce = getM
    // do something with vital force
    }

For the putter, the implementation is a function with a parameter for the new vital force.

let putM newVitalForce  =
    let doSomethingWhileLive vitalForce =
        what here ??
    M doSomethingWhileLive

Again, what should we do in the middle?

The most important thing is that the newVitalForce becomes the value that is passed on to the next step. We must throw away the original vital force!

Which in turn means that newVitalForce must be used as the second part of the tuple that is returned.

And what should be in the first part of the tuple that is returned? There is no sensible value to return, so we’ll just use unit.

Here’s the final implementation:

let putM newVitalForce  =
    let doSomethingWhileLive vitalForce =
        // return nothing in the first element of the tuple
        // return the newVitalForce in the second element of the tuple
        (), newVitalForce
    M doSomethingWhileLive

With getM and putM in place, we can now create a function that

• gets the current vital force from the context
• extracts one unit from that
• replaces the current vital force with the remaining vital force
• returns the one unit of vital force to the caller

And here’s the code:

let useUpOneUnitM =
    monster {
        let! vitalForce = getM
        let oneUnit, remainingVitalForce = getVitalForce vitalForce
        do! putM remainingVitalForce
        return oneUnit
        }

With useUpOneUnitM, we can start to rewrite all the other functions.

For example, the original function makeLiveLeftLegM looked like this, with lots of explicit handling of the vital force.

let makeLiveLeftLegM deadLeftLeg  =
    let becomeAlive vitalForce =
        let (DeadLeftLeg label) = deadLeftLeg
        let oneUnit, remainingVitalForce = getVitalForce vitalForce
        let liveLeftLeg = LiveLeftLeg (label,oneUnit)
        liveLeftLeg, remainingVitalForce
    M becomeAlive  // wrap the function in a single case union

The new version, using a monster expression, has implicit handling of the vital force, and consequently looks much cleaner.

let makeLiveLeftLegM deadLeftLeg =
    monster {
        let (DeadLeftLeg label) = deadLeftLeg
        let! oneUnit = useUpOneUnitM
        return LiveLeftLeg (label,oneUnit)
        }

Similarly, we can rewrite all the arm surgery code like this:

let makeLiveRightLowerArm (DeadRightLowerArm label) =
    monster {
        let! oneUnit = useUpOneUnitM
        return LiveRightLowerArm (label,oneUnit)
        }

let makeLiveRightUpperArm (DeadRightUpperArm label) =
    monster {
        let! oneUnit = useUpOneUnitM
        return LiveRightUpperArm (label,oneUnit)
        }

// create the M-parts
let lowerRightArmM = DeadRightLowerArm "Tom" |> makeLiveRightLowerArm
let upperRightArmM = DeadRightUpperArm "Jerry" |> makeLiveRightUpperArm

// turn armSurgery into an M-function
let armSurgeryM  = map2M armSurgery

// do surgery to combine the two M-parts into a new M-part
let rightArmM = armSurgeryM lowerRightArmM upperRightArmM

And so on. This new code is much cleaner.

In fact, we can make it cleaner yet by eliminating the intermediate values such as armSurgery and armSurgeryM and putting everything in the one monster expression.

let rightArmM = monster {
    let! lowerArm = DeadRightLowerArm "Tom" |> makeLiveRightLowerArm
    let! upperArm = DeadRightUpperArm "Jerry" |> makeLiveRightUpperArm
    return {lowerArm=lowerArm; upperArm=upperArm}
    }

We can use this approach for the head as well. We don’t need headSurgery or returnM any more.

let headM = monster {
    let! brain = makeLiveBrain deadBrain
    return {brain=brain; skull=skull}
    }

Finally, we can use a monster expression to create the whole body too:

// a function to create a M-body given all the M-parts
let createBodyM leftLegM rightLegM leftArmM rightArmM headM beatingHeartM =
    monster {
        let! leftLeg = leftLegM
        let! rightLeg = rightLegM
        let! leftArm = leftArmM
        let! rightArm = rightArmM
        let! head = headM
        let! beatingHeart = beatingHeartM

        // create the record
        return {
            leftLeg = leftLeg
            rightLeg = rightLeg
            leftArm = leftArm
            rightArm = rightArm
            head = head
            heart = beatingHeart
            }
        }

// create the M-body
let bodyM = createBodyM leftLegM rightLegM leftArmM rightArmM headM beatingHeartM

NOTE: The complete code using monster expressions is available on GitHub.

We previously used an alternative way to create the body, using applyM.

For reference, here’s that way using applyM:

let createBody leftLeg rightLeg leftArm rightArm head beatingHeart =
    {
    leftLeg = leftLeg
    rightLeg = rightLeg
    leftArm = leftArm
    rightArm = rightArm
    head = head
    heart = beatingHeart
    }

let bodyM =
    createBody
    <!> leftLegM
    <*> rightLegM
    <*> leftArmM
    <*> rightArmM
    <*> headM
    <*> beatingHeartM

So what’s the difference?

Aesthetically there is a bit of difference, but you could legitimately prefer either.

However, there is a much more important difference between the applyM approach and the monster expression approach.

The applyM approach allows the parameters to be run independently or in parallel, while the monster expression approach requires that the parameters are run in sequence, with the output of one being fed into the input of the next.

That’s not relevant for this scenario, but can be important for other situations such as validation or async. For example, in a validation context, you may want to collect all the validation errors at once, rather than only returning the first one that fails.

Dr Frankenfunctor was a pioneer in her time, blazing a new trail, but she did not generalize her discoveries to other domains.

Nowadays, this pattern of threading some information through a series of functions is very common, and we give it a standard name: “State Monad”.

Now to be a true monad, there are various properties that must be satisfied (the so-called monad laws), but I am not going to discuss them here, as this post is not intended to be a monad tutorial.

Instead, I’ll just focus on how the state monad might be defined and used in practice.

First off, to be truly reusable, we need to replace the VitalForce type with other types. So our function-wrapping type (call it S) must have two type parameters, one for the type of the state, and one for the type of the value.

type S<'State,'Value> =
    S of ('State -> 'Value * 'State)

With this defined, we can create the usual suspects: runS, returnS and bindS.

// encapsulate the function call that "runs" the state
let runS (S f) state = f state

// lift a value to the S-world
let returnS x =
    let run state =
        x, state
    S run

// lift a monadic function to the S-world
let bindS f xS =
    let run state =
        let x, newState = runS xS state
        runS (f x) newState
    S run

Personally, I’m glad that we got to understood how these worked in the M context before making them completely generic. I don’t know about you, but signatures like these

val runS : S<'a,'b> -> 'a -> 'b * 'a
val bindS : f:('a -> S<'b,'c>) -> S<'b,'a> -> S<'b,'c>

would be really hard to understand on their own, without any preparation.

Anyway, with those basics in place we can create a state expression.

type StateBuilder()=
    member this.Return(x) = returnS x
    member this.ReturnFrom(xS) = xS
    member this.Bind(xS,f) = bindS f xS

let state = new StateBuilder()

getS and putS are defined in a similar way as getM and putM for monster.

let getS =
    let run state =
        // return the current state in the first element of the tuple
        state, state
    S run
// val getS : S<State>

let putS newState =
    let run _ =
        // return nothing in the first element of the tuple
        // return the newState in the second element of the tuple
        (), newState
    S run
// val putS : 'State -> S<unit>

Before moving on, how do we know that our state implementation is correct? What does it even mean to be correct?

Well, rather than writing lots of example based tests, this is a great candidate for a property-based testing approach.

The properties we might expect to be satisfied include:

• The monad laws.
• Only the last put counts. That is, putting X then putting Y should be the same as just putting Y.
• Get should return the last put. That is, putting X then doing a get should return the same X.

and so on.

I won’t go into this any more right now. I suggest watching the talk for a more in-depth discussion.

We can now use state expressions exactly as we did monster expressions. Here’s an example:

// combine get and put to extract one unit
let useUpOneUnitS = state {
    let! vitalForce = getS
    let oneUnit, remainingVitalForce = getVitalForce vitalForce
    do! putS remainingVitalForce
    return oneUnit
    }

type DeadLeftLeg = DeadLeftLeg of Label
type LiveLeftLeg = LiveLeftLeg of Label * VitalForce

// new version with implicit handling of vital force
let makeLiveLeftLeg (DeadLeftLeg label) = state {
    let! oneUnit = useUpOneUnitS
    return LiveLeftLeg (label,oneUnit)
    }

Another example is how to build a BeatingHeart:

type DeadHeart = DeadHeart of Label
type LiveHeart = LiveHeart of Label * VitalForce
type BeatingHeart = BeatingHeart of LiveHeart * VitalForce

let makeLiveHeart (DeadHeart label) = state {
    let! oneUnit = useUpOneUnitS
    return LiveHeart (label,oneUnit)
    }

let makeBeatingHeart liveHeart = state {
    let! oneUnit = useUpOneUnitS
    return BeatingHeart (liveHeart,oneUnit)
    }

let beatingHeartS = state {
    let! liveHeart = DeadHeart "Anne" |> makeLiveHeart
    return! makeBeatingHeart liveHeart
    }

let beatingHeart, remainingFromHeart = runS beatingHeartS vf

As you can see, the state expression automatically picked up that VitalForce was being used as the state – we didn’t need to specify it explicitly.

So, if you have a state expression type available to you, you don’t need to create your own expressions like monster at all!

For a more detailed and complex example of the state monad in F#, check out the FSharpx library.

NOTE: The complete code using state expressions is available on GitHub.

The state computation expression, once defined, can be used for all sorts of things. For example, we can use state to model a stack.

Let’s start by defining a Stack type and associated functions:

// define the type to use as the state
type Stack<'a> = Stack of 'a list

// define pop outside of state expressions
let popStack (Stack contents) =
    match contents with
    | [] -> failwith "Stack underflow"
    | head::tail ->
        head, (Stack tail)

// define push outside of state expressions
let pushStack newTop (Stack contents) =
    Stack (newTop::contents)

// define an empty stack
let emptyStack = Stack []

// get the value of the stack when run
// starting with the empty stack
let getValue stackM =
    runS stackM emptyStack |> fst

Note that none of that code knows about or uses the state computation expression.

To make it work with state, we need to define a customized getter and putter for use in a state context:

let pop() = state {
    let! stack = getS
    let top, remainingStack = popStack stack
    do! putS remainingStack
    return top
    }

let push newTop = state {
    let! stack = getS
    let newStack = pushStack newTop stack
    do! putS newStack
    return ()
    }

With these in place we can start coding our domain!

Here’s a simple one. We push “world”, then “hello”, then pop the stack and combine the results.

let helloWorldS = state {
    do! push "world"
    do! push "hello"
    let! top1 = pop()
    let! top2 = pop()
    let combined = top1 + " " + top2
    return combined
    }

let helloWorld = getValue helloWorldS // "hello world"

Here’s a simple stack-based calculator:

let one = state {do! push 1}
let two = state {do! push 2}

let add = state {
    let! top1 = pop()
    let! top2 = pop()
    do! push (top1 + top2)
    }

And now we can combine these basic states to build more complex ones:

let three = state {
    do! one
    do! two
    do! add
    }

let five = state {
    do! two
    do! three
    do! add
    }

Remember that, just as with the vital force, all we have now is a recipe for building a stack. We still need to run it to execute the recipe and get the result.

Let’s add a helper to run all the operations and return the top of the stack:

let calculate stackOperations = state {
    do! stackOperations
    let! top = pop()
    return top
    }

Now we can evaluate the operations, like this:

let threeN = calculate three |> getValue // 3

let fiveN = calculate five |> getValue   // 5

People always want to know about monads, even though I do not want these posts to degenerate into yet another monad tutorial.

So here’s how they fit in with what we have worked with in these posts.

A functor (in a programming sense, anyway) is a data structure (such as Option, or List, or State) which has a map function associated with it. And the map function has some properties that it must satisfy (the “functor laws”).

A applicative functor (in a programming sense) is a data structure (such as Option, or List, or State) which has two functions associated with it: apply and pure (which is the same as return). And these functions have some properties that they must satisfy (the “applicative functor laws”).

Finally, a monad (in a programming sense) is a data structure (such as Option, or List, or State) which has two functions associated with it: bind (often written as >>=) and return. And again, these functions have some properties that they must satisfy (the “monad laws”).

Of these three, the monad is most “powerful” in a sense, because the bind function allows you to chain M-producing functions together, and as we have seen, map and apply can be written in terms of bind and return.

So you can see that both our original M type and the more generic State type, in conjunction with their supporting functions, are monads, (assuming that our bind and return implementations satisfy the monad laws).

For a visual version of these definitions, there is a great post called Functors, Applicatives, And Monads In Pictures.

There are a lot of posts about state monads on the web, of course. Most of them are Haskell oriented, but I hope that those explanations will make more sense after reading this series of posts, so I’m only going to mention a few follow up links.

• State monad in pictures
• “A few monads more”, from “Learn You A Haskell”
• Much Ado About Monads. Discussion about state monad in F#.

And for another important use of “bind”, you might find my talk on functional error handling useful.

If you want to see F# implementations of other monads, look no further than the FSharpx project.

Dr Frankenfunctor was a groundbreaking experimentalist, and I’m glad that I have been able to share insights on her way of working.

We’ve seen how she discovered a primitive monad-like type, M<BodyPart>, and how mapM, map2M, returnM, bindM and applyM were all developed to solve specific problems.

We’ve also seen how the need to solve the same problems led to the modern-day state monad and computation expression.

Anyway, I hope that this series of posts has been enlightening. My not-so-secret wish is that monads and their associated combinators will no longer be so shocking to you now…

…and that you can use them wisely in your own projects. Good luck!

NOTE: The code samples used in this post are available on GitHub.