Tag Archives: functional programming

Monads in Clojure: Monadic tree labelling with the State monad

Generally speaking there are way too many tutorials on monads on the web, though not many that are specific to Clojure (Konrad Hinsen’s tutorial being an obvious exception.) The argument as I’ve seen it described is that too many people figure out monads, then immediately attempt to explain their understanding of monads without realising that people have to figure things out in their own way.

This is an attempt to to something slightly different: to expose my thinking as I am in the process of learning things for myself, and before I get too comfortable with the ideas and set in my ways. It is, in other words, a monad tutorial written by a guy who knows nothing about monads. I don’t really know whether this will be helpful to other people or not, but I figured it was worth a shot.

The observant among you will probably get the impression that the log below isn’t written as I think it, but after a period of reflection. Nevertheless, I attempt to detail my thought processes without too much retrospective alteration.

So, monads then. Brian Beckmann wants me to think of them like function composition with extra type-decoration in some way. Konrad Hinsen makes them look a lot more like a sort of specialised let-binding, although as any avid lisper knows, let-bindings are little more than syntactic sugar for anonymous functions.

What strikes me immediately is how different monads look in Haskell from in Clojure. This is aggravated by me knowing almost nothing of Haskell. Monad programs in Haskell are littered with functions, commonly from inscrutable types to pairs of inscrutable types. In Clojure, they look an awful lot like let bindings, where most of work seems to be carried out in the binding with a trivial body.

Monads are available in Clojure contrib, so getting them hooked up is easy:

(ns uk.co.asymptotic.mucking.about.with.monads
   (:use clojure.contrib.monads))

The most obvious thing to try is the identity monad, which is hopefully the simplest case to understand. This acts exactly like a let binding:

  [a 2
   b 21]
  (* a b))

returns 42. This is exactly the same result as

  [a 2
   b 21]
  (* a b))

So far, so good. We could obviously attach some sorts of transformation functions to the bindings, but this can hardly be what all the fuss is about. Monads have to be more than a simple macro transformation to a let binding.

One of Konrad Hinsen’s examples looks interesting: a monad expression can be used to mimic the effect of a for expression as well as a let expression. This isn’t too far removed from a let expression, but something else is going on: the inner expression is being executed multiple times, and the eventual return value wraps these intermediate results into a list.

  [a (range 1 5)
   b (range 1 5)]
  (* a b))

=> (1 2 3 4 2 4 6 8 3 6 9 12 4 8 12 16)

So changing the monad in syntactically almost identical code has caused the inner expression to get evaluated multiple times. This hints at why monads are most naturally of use in functional languages, since we don’t care how many times something was executed, only about its result (since functions are pure).

It also occurs to me that changing the monad has kept the overall form the same, but changed the values I can work with in the “let-binding” part of the monadic expression. It looks like all domonad expressions are going to look similar, but I can’t freely swap monads in and out without paying attention to the types of the values in the binding expression. It’s not surprising that we don’t have complete latitude here, but for the monad technique to be anything but an obfuscation we must have some independence between the expression and the monad we apply to it.

It occurs to me that this last detail may be something that works out better in Haskell, with its more visible type system. There must be some relationship between the type of the monad and the types of the expressions I can write under that monad, but in a dynamically-typed language it seems far too much like trial and error. But then, I’ve always felt that about typing in dynamically-typed languages.

So we can cause functions to be evaluated multiple times with monads. We can also cause code not to be evaluated, via the frequently-described maybe monad. The maybe monad seems to go further, and allow us to interfere with the execution of functions that are within the binding part of the expression:

 [a nil
  b (/ 1 0)]
 (+ a b))

This returns nil, indicating that we never got as far as the division by zero. This begins to sound like quite a powerful idea — we can control which code is evaluated from outside of the code itself, simply by changing the monad. But how general is this idea? So far we’ve only succeeded on using it on code written in a rather unnatural let-binding style, and I’ve had to come up with a new case to use each monad. If code can’t be reused, then I may as well hard-code the logic and get on with my life.

Monad enthusiasts (doesn’t that sound like someone you don’t want to get stuck next to on a train?) often wax lyrical about how monads can be used to model things as diverse as state (in an otherwise stateless program), continuations and I/O. This is an appealing prospect—these are all things that seem to need special rules and representations baked into the programming language, and it would be pleasing to see them all described within a single theoretical framework. However, there’s not much sign of that in the progress so far.

At this point I’m going to pick up on one of Brian Beckman’s examples, namely the state monad. This shows a hint of getting us towards continuations and other such goodies. In order to make any sense of Beckman’s examples I had to go away and spend a few days learning Haskell. I figured if I could rewrite his Haskell example in Clojure I had a shot at claiming I could understand what is going on.

So I start by defining a tree:

(defstruct node :left :right)

  (struct node :a :b)
  (struct node (struct node :c :d) :e)))

This isn’t going to win any awards for extensible Clojure code, but it’ll probably do the trick. I’m going to be using the implementation of the state monad as provided in Konrad Hinsen’s monad library (part of Clojure contrib), which gives me a couple of utility functions:

(defn update-state [f]
  (fn [s] (list s (f s))))

(defn set-state [s]
  (update-state (fn [_] s)))

(defn fetch-state []
  (update-state identity))

The names and input types of these functions look like exactly what we want in order to do stateful programming. However, the return values are inscrutable. I request the state gets updated, and all that happens is I get a function passed back to me. What’s up with that?

Never mind, I’ll push ahead and write it in the most obvious way possible, following the structure of Beckman’s example:

(defn label-tree [tree]
  (if (map? tree)
     [labelled-left (label-tree (:left tree))
      labelled-right (label-tree (:right tree))]
     (struct node labelled-left labelled-right))
     [val (fetch-state)
      _ (update-state #(+ 1 %))]
     [tree val])))

I’ve cribbed heavily from Beckman’s code, and it’s not very idiomatic as I’ve had to replace Haskell pattern matching with an if, and forced it into the domonad binding form. Furthermore, it’s not at all clear why the fetch-state and update-state calls work the way they do. Assuming the domonad form to be simple let-binding with some embellishment it makes no sense to have functions like fetch-state and friends that return functions.

I’ll leave understanding it until later. First to see whether it works:

(label-tree tree)

=> #<monads$fn__475$m_bind_state__482$fn__483 clojure.contrib.monads$fn__475$m_bind_state__482$fn__483@c10de0>

That’s not what I expected. This looks like some sort of function object. But what is it expecting as an argument? Clearly I’ve not understood this. This isn’t what happened when I used the identity or maybe monads. Then I got a result straight back from the domonad call, not a function. Further hints that not everything in monad land is regular and substitutable.

Back to Beckman’s state monad tutorial. He emphasises that an instance of the state monad is a function from a state to a state-contents pair. Composing state monads gives more state monads, with successively more complex functions between state and state-contents pair, but always with the same signature. This is a hint. No matter how many I compose and how I compose them, I’ll always have an input that is demanding a state. This makes sense—I defined a function to update the state from one node to the next, but I didn’t tell it where to start from. Putting the initial state in as a function parameter seems like a good idea:

((label-tree tree) 0)

=> ({:left {:left [:a 0], :right [:b 1]}, :right {:left {:left [:c 2], :right [:d 3]}, :right [:e 4]}} 5)

Victory is mine! The tree has been labelled, and the code did the right thing first time. Crucially, it seems in some sense more natural than the more obvious functional solution of passing the state around as an extra parameter in and a tuple result out of functions. The use of the monad looks like what you’d like to write in a stateful programming language, and the binding and passing happens transparently.

As a side note, the call to label-tree is obviously something that would look cleaner in Haskell than it does in Clojure, since in the former we can simply list the parameters as if we were calling a two-parameter function. In fact, the question of the exact difference between the monad call followed by binding the second parameter and a genuine two-parameter function is beyond my meagre understanding of Haskell. Obviously we could hide this syntactic issue by declaring label-tree as a 2-argument function that does the monad call and then applies the state, but it’s a slight let-down to find that this is necessary.

So it appears that the domonad call hasn’t actually done anything, but has produced a single heinously complicated function of what we would do when given a state. Crucially, the content of the tree itself has been built into the very structure of this function. The state travels through the function in a deterministic fashion and is permuted in various ways that are, by the time the monad has been instantiated, completely pre-determined.

I still have questions about monads. It still looks like a trick, albeit an elegant one. It’s not at all clear to me where using a monad will be preferable to simply writing idiomatic Clojure code. The domonad syntax still swears at me by looking entirely unlike ordinary Clojure code. Nevertheless, I feel I’m a step closer to understanding it all.

First impressions of F#

I’ve just read through Foundations of F# and written one or two trivial scripts in F#, so it’s too early to make a proper balanced assessment of it as a language. However, I wanted to record my immediate reactions to it so far while they are still fresh in my mind.

I don’t have a strong background in functional programming, but I’ve dabbled with Common Lisp, Haskell, Clojure and Scala. I’m excited by the new trend of functional languages targetting the JVM and .Net CLR, since this seems to solve the major problem with functional languages of the past in not having library code in sufficient quantity and quality.

Targetting either of the widely available virtual machines seems to be a double-edged sword, however. From what I can tell neither the JVM nor the CLR are well suited to functional languages. Clojure, Scala and F# all seem to have (and I’m being polite here) idiosyncracies forced upon them by the underlying runtime.

My immediate reaction to F# is that it seems to work hard to make it easy to interact with OO languages on the CLR, at the expense of being a great functional language in its own right. Haskell and Clojure both have strong (and different) concepts of lazy evaluation that permeate the language and let you program in a whole new way. If F# has this, it’s not been obvious to me in the first couple of hours using it.

Nor (as far as I can tell) does F# have particularly good support for parallelisation, which is one of the key advantages of functional programming for me. In my opinion Clojure has the strongest claim here, having been built from the ground up to be parallelised safely. Haskell apparently has very strong tool support in the form of ghc. What does F# offer in this direction? It’s not at all clear to me, but with the ability to create mutable fields with a single keyword, and no support for inferring immutability via the type system, it doesn’t fill me with confidence.