If you have an affinity for programming language theory (as I do), and wander around the internet searching for topics of interest, eventually you will run into references to monads. They’re neither trivial, nor as complex as the dearth of proper explanations of them might suggest.
In a nutshell, they are the PLT manifestation of a concept from category theory, and abstract away propagation of results and side effects, without actually performing side effects or leaving a pure-functional paradigm. Any attempt at description beyond that point tends to either
- a) get terribly botched*, or
- b) turn into a real category theory explanation, which most people don’t have the background to understand easily
and for those reasons I will refrain from attempting further explanation myself. I don’t have confidence in my own ability to explain in a non-interactive medium, and I certainly don’t have the mathematics background to formalize it.
The internet is littered with tutorials and explanations “in laymen’s terms” of what monads are, what they are for, why we care, etc. Every such tutorial I have started (at least a dozen, probably several more – all highly recommended) has either bored me to tears, struck me as completely inane, or simply confused me.
I had decided that I was simply going to have to learn abstract algebra and category theory in order to really get a handle on what they were, until a wonderful post appeared on LtU, linking to one of the earlier papers on monads. The paper, by Philip Wadler, gives not only a clear explanation of what a monad is, but also provides a strong motivation for looking for monads, an approachable description of how they are derived from a practical point of view for use in a type system, and a number of useful, nontrivial examples. Probably one of the most well-written academic papers I’ve read. You should be familiar with an ML-style type system and notation to understand the examples. Or you need be be good at picking up such things on the fly.
Monads for Functional Programming. Enjoy.
* The canonical example of a monad is for some reason the Maybe monad, though I don’t know why – it’s certainly a monad, but it’s actually not the most intuitive first example. Most of the monad explanations I found online immediately launch into using Maybe as an example of why monads aren’t hard. They’re not, but the example is usually provided far too early, without enough background, motivation, or explanation, making the reader simply feel like he or she is missing some greater complexity (which is true) which was already explained (which usually is not the case). Wadler’s example of a simple interpreter is much clearer.
A Ham Sandwich 
Heh, i just posted this comment about explanations of Haskell Monads to the haskell-cafe list. 🙂
I was looking for an explanation more halfway between category theory and the basic ‘What is a Monad in Haskell’ question, but what you posted is certainly along the right lines. Just make sure you end up giving a good explanation of why we care about monads.
Being responsible for two instances of that awfulness (monads as space suits, and as nuclear waste [*]), I feel that I must apologise. Believe me, you aren’t the only reader to have found themselves exasperated by the inanity of the tutorial or the insistance on sticking to the metaphor.
That said, I wonder what you made of the sigfpe tutorial. It seems to avoid the sins of bullshittery and strikes a delicate balance between showing you that they are easy and not trying to pass them off as trivial.
For a bit of background, maybe to share the plight of a monad-tutorial-writer, I mostly wrote that tutorial to teach myself about monads. At the time, I knew only about ‘All about Monads’ and the YAHT tutorial, which I found myself struggling with. So I took stock of what I think I got, and then tried explaining it in my terms, simple “mechanical” and “moving-parts”-ish. Some people have found it helpful — writing it at least made me feel comfortable enough to use them with some success — but I’m always worrying that I’ve let somebody walk away with the wrong idea, that I’ve deceived them (and myself) into think they understood monads when in fact I’ve just made us all miss the point completely. Somebody remarked that, “yeah, it’s just a like a FP design pattern”… which I’m not sure I would be comfortable with.
[*] the latter metaphor was proposed by a wikibookian who found the imagery of the first one ‘far fetched’ (a space suit for more than one person?). Unfortunately, the new metaphore gets things ‘backwards’ in the sense that the thing that is inside the container is the ‘dangerous’ stuff, nuclear waste, oh my! But I suppose this illustrates the danger of trying to explain something like this with a metaphor.
Assuming you’re referring to this one, I had found it before running across the above paper linked from Lambda the Ultimate. I don’t think I read it at the time I found it because I had gotten annoyed at some number of other tutorials earlier in the day, and dumped it into my del.icio.us bookmark list – which is really just a black hole.
Looking through it now, it does seem pretty good. I think I still prefer the paper, because it is extremely thorough, and I think the pace works better in the paper, as the sigfpe one is a little quick. I do wish I’d actually bothered to read this the first time :-p
You know, if you wanted the category theory background for monads (though not the applications to programming, as yet), it’s all up under the “category theory” tag at my weblog…
Incidentally, I just found your blog earlier today linked from reddit, thanks!
[…] Monads! (and Why Monad Tutorials Are All Awful) « A Ham Sandwich – I agree, most monads tutorials leave thinking “So what?”. […]
[…] than two weeks after starting this blog, I ended up on programming.reddit.com (direct link) for this entry on the fact that most monad tutorials are awful, and offering a pointer to a paper . […]
Hi,
I’m late, I know, but still I’m one of the authors of those boring monads tutorials. Well, I’m surprised that you read them all – there are not so many actually – and you had to wait for a post on lambda the ultimate to find out about Wadler’s paper.
Indeed my tutorial, http://haskell.org/haskellwiki/The_Monadic_Way/Part_I, pretends to be a “translation” of Philip Wadler’s “Monads for functional programming”. I’m not saying it is a useful or good translation, but tries to make clear that Wadler’s paper IS the paper to read if you want to understand monads. I was first in stating that. You come second.
Andrea
@ Eric Kow,
There was a month a long time ago that I spent almost all my free time trying to understand monads, and I read quite a few tutorials and found none of them helpful. I saw yours but then because it was about space suits I thought it would be a load of bollocks.
A few months passed and then I tried again, and this time I looked at your tutorial and I managed to understand it in two days. It is my opinion that your tutorial is perhaps the best on the internet but could be improved because it does require a bit of exposure to monads.
-Tahir
The simplest way to think about a monad is to realize that every function/program is a “hylomorphism” — consists of an unfolding of a data structure, piece-wise function application, and then a folding into a new data structure (“rendering”).
This is even true for plain Haskell functions (pattern matching handles the “parsing” step, rendering is either done by the identity (in the trivial case) or “show”). However, we can use an algebraic/category theoretic concept (“the monad”) to encapsulate the folding and unfolding of a data structure into another.
The monad defines a “bind” operator >>=, which takes a monad element and a function on the monad element’s underlying type back to the monad. The monad element is unfolded (as defined by >>=), and f is applied to refold it, perhaps in terms of a different kind of data structure.
Of course, a parser is automatically a state machine and lots of other “equivalent” things, and so by changing the emphasis of interpretation, one can construct them all using the same simple Haskell notation.
From a different point of view, a programming language’s “object system” is a specific monad operating on a tree of object-oriented classes to seek methods. “Generalized object systems” can be built, and the monads are them.
The simplest way to think about a monad is to realize that every function/program is a “hylomorphism” — consists of an unfolding of a data structure, piece-wise function application, and then a folding into a new data structure (“rendering”).
This is even true for plain Haskell functions (pattern matching handles the “parsing” step, rendering is either done by the identity (in the trivial case) or “show”). However, we can use an algebraic/category theoretic concept (“the monad”) to encapsulate the folding and unfolding of a data structure into another.
The monad defines a “bind” operator >>=, which takes a monad element and a function on the monad element’s underlying type back to the monad. The monad element is unfolded (as defined by >>=), and f is applied to refold it, perhaps in terms of a different kind of data structure.
Of course, a parser is automatically a state machine and lots of other “equivalent” things, and so by changing the emphasis of interpretation, one can construct them all using the same simple Haskell notation.
From a different point of view, a programming language’s “object system” is a specific monad operating on a tree of object-oriented classes to seek methods. “Generalized object systems” can be built, and the monads are them.
We’re a group of volunteers and starting a brand new scheme in our community. Your web site offered us with useful info to work on. You have done an impressive activity and our whole group will be grateful to you.