Lambda the Ultimate

The initial discussion (of Maybe, and the parentage of cloned livestock) is excellent, and helpful in that provides a meaningful context in which to introduce the nuts and bolts of monads before we get to a discussion of those members of the "awkward squad" that monads are used to tackle. I think this is a smart move, because it makes it easier to see why monads are a good approach to take to these issues. Other tutorials I've read have tended to say, in effect, "State and I/O are a problem, and Haskell has this weird, obscurely-named and difficult-to-understand mechanism for getting around that problem, which I will now endeavour to explain to you", which is not encouraging.

Browsing ahead, this looks like it deals with some of the harder (for a newb) questions about monads, such as how you combine monadic actions of different types, in a timely fashion; which is good, because if you're impatient like me you'll have started asking those questions long before some treatments of the subject get to them (if they get to them at all).

This is really useful!

But I think it is worthwhile to discuss the different approaches for handling state and IO in pure languages (CPS etc.), and see how monads are related to them.

As in this example?

Unlike when I first read this discussion, I now have some idea what "lifting over a backtracking monad" might mean...

Perhaps less intimidatingly (I am quite hopelessly out of my depth with much of this sort of thing), you could compare two approaches to nondeterminism - the list monad, and the implementation of (amb) using call/cc discussed in "Teach Yourself Scheme in Fixnum Days".

Great! Your tutorial is very good, so it's well worth it to spend the time to make it even better.

Here - just to scrape some fingernails down people's inner blackboards - is a (no doubt rather wonky) OO/Imperative analogy for monadic actions:

Consider a Command object that implements a method that receives a representation of the state of a process, and returns a representation of the state of that process after the command has been executed.

Now consider a Command object that contains a sequence of smaller Command objects - Sub-commands. When this Command's "execute" method is called, the initial state-representation is passed to the first Sub-command in the sequence, and the modified state-representation returned by that Command is then passed to the next Sub-command in the sequence. All of the Sub-commands are chained together in this way, and the modified state-representation returned by the last Sub-command is finally returned by the Command object.

Now consider a Command object that may fail, and that contains a sequence of chained Sub-commands that must fail if any one of the Commands in the sequence fails. Also consider a Command object that passes the same initial state-representation to each of its Sub-commands in turn (i.e. without chaining them together) until one of them does not fail, and then returns the return value from that Sub-command without troubling to execute any of the others.

Given the ability to compose Commands by adding them to sequences of Sub-commands maintained by other Commands, and the ability to either chain Sub-commands together or try them out one at a time with the same initial conditions, it is possible to implement nondeterministic processes of various sorts, backtracking whenever some sub-sequence of processes fails. The key to this is of course the ability to create, modify and pass around representations of the state of the process.

What happens inside a Parser monad is similar to the above, except that functions are used instead of Command objects, and function composition (using an infix operator) is used instead of storing nested sub-sequences of Commands inside each other...

I haven't looked at Jeff's tutorial yet, though it's on my list.

Yes. Plenty of good stuff in this paper. Useful alternative (and source of examples) for The Little Haskellist...

Thanks to all of the people that sent in suggestions and criticisms!