If all you want to do is learn to program Haskell, then I think the existing
explanations
of monads suffer too much from history. A few years ago we had (>>) and (>>=), but no
"do"
notation. Afterwards "do" was invented, making everyone's life easier. I suggest that
introductions to Haskell stop treating "do" as syntactic sugar for (>>) and (>>=), and
instead
treat (>>) and (>>=) as syntactic sugar for "do" (if they teach them at all). Thus
all you
need to explain is "do" (which is in almost all respects identical to impure
sequencing
constructs in impure languages), and the IO typeconstructor. The latter is the only
real new construct (an "IO a" is a way of obtaining an a, not an a). By the time
novices learn monads they should already have learnt something about pure functional
programming, so they should be able to resist the temptation to write all their
functions
as actions.
Of course, in more advanced courses you will probably have to explain (>>=), as
otherwise
people can't define their own instances of Monad. (Fortunately, one can write quite a
lot
of Haskell without having to instance Monad.) However there is no other reason I can
see
for ever using (>>) and (>>=). In my opinion, Haskell has far too many infix operators
which allow you to save a few characters at the expense of making your code much
harder to
read. This is bad style in Haskell just as much as in C.
