Review: Monads for Functional Programming

Monads for Functional Programming, by Philip Wadler, 1992.

After reading this paper, I think I finally have an intuition for what monads are. They're basically a fold over computations: unit is used to transform values, and bind is used to transform unary function application. The fact that a monad can only fold over unary application is, one would hope, not limiting because of currying (but I'm not sure). The monad laws can be thought of as restricting the fold to having semantics similar to function application (respectively: referential transparency, lambda abstraction, and composition).

All monads have a type argument. My understanding of why this is necessary is because functions are opaque, and the only thing you can do with them is apply them to the exact type that they expect. Therefore the original value must be shuttled through the monad so that it can be passed to the functions that are being folded over. One alternative would be to not apply the function at all, but that only works if your intention is to abort the computation (the way exception monads do). You certainly can't keep following the original computation, because functions are black boxes that are useless for anything other than being applied to a value.

Because monads always wrap an underlying type with additional information, an alternate intuition is to think of a monad-wrapped type as a subclass in an OO language, with the original type being the base class. In this view, unit is basically a factory method. However, I'm not sure the monad laws have any meaning in this point of view, and it's even difficult to find an OO analog for bind.

I think the paper would have been better if the long discussion of particular monads (array reader/writer, parser, etc) had been replaced with a discussion of how to combine monads (after all, imperative programming lets you use state and exceptions and I/O, all at the same time). Perhaps he was trying to give a feel for where Monad research was going, but I don't think that's appropriate for a paper that starts out as didactic as this one does.

My intuition is telling me that monads are not really an optimal technique for adding semantics to computations, for two reasons. One, they're restricted to unary function application. Two, functions are useless for anything other than application. I have the feeling that Monads do not, in general, approach the power of abstract interpretation.

Read more reactions to this paper on the Advanced Functional Programming wiki.