[Haskell-cafe] Explaining monads

[Dan Piponi]

On 8/14/07, Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
> Well that's easy, don't use the recipe analogy to explain code, use it
> for monadic values exclusively, and you avoid the confusion entirely!
>
> I don't think it's that complicated.

It certainly is complicated. I think I have a good grasp of monads to
the point where I can tease novel monads (and comonads) out from
algorithms that people previously didn't see as monadic. And yet I
still don't understand what you are saying (except with respect to one
specific monad, IO, where I can interpret 'action' as meaning an I/O
operation).

> Monads have a monadic type. They
> represent an abstract form of an "action", which can be viewed as an
> analogy to real-world cooking recipes.

All functions can be viewed as recipes. (+) is a recipe. Give me some
ingredients (two numbers) and I'll use (+) to give you back their sum.

> As long as you don't
> deliberately confuse things by using the same analogy for two
> different things I don't see where confusion would set in.

If I was one of your students and you said that monads are recipes I
would immediately ask you where the monads are in my factorial program
regardless of whether you had introduced one or two different
analogies for recipes. There are two sides to every analogy. If you
have an analogy between A and B then you can use knowledge about A to
understand B. But conversely, if you can't set up the same analogy
between A and B then that tells you something useful about B also. As
far as I can see, your description of a monad fits every computer
program I have ever written, and as a result I don't see what it is
that makes monads special. And monads are special.
--
Dan