[Haskell-cafe] Monad Description For Imperative Programmer

[Dougal Stanton]

On 02/08/07, Alexis Hazell <dry.green.tea at gmail.com> wrote:


> It's at this point that i feel there's an issue. Haskell Monads are used FOR
> many many things. And rather than get to the core of what a Monad is, many
> people provide two or three motivating examples - examples which merely serve
> to show /some/ of what Monads are about, but which will lead astray any
> person who incorrectly assumes that these two or three examples constitute
> the totality of the Monadic universe, and who makes inferences about Monads
> accordingly. (To me, the notion that a Monad is merely a kind of loop is an
> example of this.)

I agree with this very much. Monads are used for a great deal of
things, some of which seem related (IO/State, []/Maybe) while others
are utterly disconnected.

Simon Peyton Jones has jokingly said that "warm fuzzy things" would
have been a better choice of name. In seriousness, though, I think the
exact name is not the problem. I would suggest that *having a name* is
the problem.

In imperative programming there are many idioms we would recognise.
Take the "do something to an array" idiom:

for (int i = 0; i < arr.length; i++) {
    arr[i] = foo(arr[i]);
}

This is a pretty obvious pattern. Some might say it's so obvious that
it doesn't need a name. Yet we've got one in functional programming
because we can. Without higher-order functions it's not possible to
encapsulate and name such common idioms. It seems a bit superfluous to
name something if you can't do anything with the name.

But with higher-order functions we *can* encapsulate these ideas, and
that means we *must* name them. Add to that the insatiable
mathematical desire to abstract, abstract, abstract...

Intuitively it seems that monads are similar, except the instances are
much less obviously connected. It's easy to see the connection between
State and IO. But those two to []?

Do I have an suggestions? Well, maybe the right way would be to do as
we do with map and fold, etc: show the explicitly recursive example,
then generalise. So, show how we could we would thread state in
Haskell, or how we would do optional (Maybe-style) values, then
generalise, *slowly* coalescing the more similar monads first before
reaching the 'top' of the monadic phylogenetic tree.

Hmm, I can see that previous paragraph is not as clear as it could be.
But anyway: has anyone used this approach before?

Cheers,

D.