Ashley Yakeley comments:

Jerzy Karczmarczuk wrote:

...

Monads are *much* more universal than that. They are "convenient patterns" to code the non-determinism (lazy list monads), to generalize the concept of continuations, to add tracing, exceptions, and all stuff called "computation" by the followers of Moggi. They are natural thus to construct parsers. Imperative programming is just one facet of the true story.

Perhaps, but mostly monads are used to model imperative actions. And their use in imperative programming is the obvious starting point to learning about them.

"Mostly" is very relative. The real power of monads is their universality. This "modelling of imperative actions" is just a way to hide the State, which in IO is rather unavoidable. But in my opinion it is rather antipedagogic to introduce monads in such a way to beginners. "Obvious starting point"? My goodness, but this is selling a black, closed box, which smells badly (imperatively) to innocent souls. People see then just do rubbish <- rubbish more_rubbish and don't know anything about the true sense of return, of the relation of <- to >>=, and finally they can use ONLY the IO Monad, nothing else. They start posing questions what is the difference between a <- b and let a = b ... and they get often ungodly answers to that, answers which say that the main difference is that <- "executes side-effects", and let doesn't. It choked me a bit. (Was it on comp.lang.functional, or on one of Haskell lists?) My philosophy is completely opposite. Introduce Monads as a natural way of chaining complex data transfer and hiding useless information, and when the idea is assimilated, then pass to IO. I begin usually with Maybe, then with backtrack Monad, and some simple State Transformers. Then, the students can grasp the Wadler's style slogan "Monads can Change the World". Oh, well, all teaching approaches are imperfect. Jerzy Karczmarczuk Caen, France