[Haskell-cafe] Teaching Monads

[Ronald Guida]

Monads in Haskell are a topic that I, like most beginners, find
difficult and "mind-twisting".  Now that I think I understand monads,
they seem to be very simple; I've read that this is a common
experience.

So I wonder, what would it take to help beginners catch on with a
minimum of fuss or frustration?  The plethora of monad tutorials out
there is clear evidence that plenty of others have wondered the same
thing.

What made monads "click" for me is when I understood the following
things:

1. When monads are being used, closures are almost always involved.

2. These closures naturally arise when desugaring do-syntax.

 do x1 <- m1               m1 >>= (\x1 ->
    x2 <- m2               m2 >>= (\x2 ->          [Eq1]
    x3 <- m3               m3 >>= (\x3 ->
    return (f x1 x2 x3)    return (f x1 x2 x3))))

3. These closures are extremely similar to the closures that arise
   when desugaring let-syntax.

 let x1 = f1 in            f1 -$ (\x1 ->      Where:
   let x2 = f2 in          f2 -$ (\x2 ->      (-$) :: a -> (a -> b) -> b
     let x3 = f3 in        f3 -$ (\x3 ->      x -$ f = f x
       f x1 x2 x3          f x1 x2 x3)))

4. While I can think of a monad as a fancy container that holds an
   element of type "t", it might be more accurate to think of a monad
   as a container that merely displays the type "t" as a label for its
   contents. The container might hold one object of type "t", or it
   might hold several.  It might not be holding any at all.  Perhaps
   the container /never/ holds an object of type "t", but instead it
   holds a set of instructions to produce such an object.
   (e.g. Reader, State).

Naturally, it's hard to illustrate nested closures, higher-order
functions, and objects that aren't really there.  It's easy to
illustrate a sequential scheme where a single "thing" passes through a
series of operations, while some related data travels in parallel.

                   m1 >>= f1 >>= f2 >>= f3        [Eq2]

In any case, the extreme similarity between desugared "do" and
desugared "let" leads me to think of the concepts of a manual
plumbing system and a monadic plumbing system.

Basically, a manual plumbing system is what I have if I'm threading
information down through a series of nested function calls in a
certain stereotypical way.  A monadic plumbing system is what I get
when I introduce the appropriate monad to encapsulate my threading.

In fact, if I look at Wadler [*], there are three examples of an
evaluator that use what I'm calling "manual plumbing".  In section
2.5, the operations required of a monad (return, bind) pretty much
just drop right out.  Wadler even points out the similarity between
"bind" and "let".

Now that I finally "get it", I feel that the Wadler paper, section 2.5
in particular, is probably a better introduction than many of the
monad tutorials out there.  Moreover, I feel that for /some/ of
the tutorials out there, they spend too much time and too many
illustrations explaining things like [Eq2], and then they quickly
present do-notation and gloss over [Eq1].

For me, I found that that the concepts of "manual plumbing" and
"monadic plumbing" were key to actually grasping the Wadler paper and
understanding what monads are.  In particular, I feel that these two
concepts might be a way to help other beginners catch on as well.

OK, so before I attempt to write a monad tutorial based on "manual
plumbing" and "monadic plumbing", I would like to know, does anyone
else think this is a good idea?

[*] "Monads for Functional Programming".
(http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf)