[Haskell-cafe] Explaining monads

Sebastian Sylvan sebastian.sylvan at gmail.com
Tue Aug 14 15:13:30 EDT 2007

On 14/08/07, Dan Piponi <dpiponi at gmail.com> wrote:
> 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.

No, (+) is a function, not a "recipe". Again, you're introducing
confusion because you use the same analogy for two *different* things.
Use it for one of the things and you don't have that problem.
I want to use "recipe" to mean "an abstraction for an action". It
could litterally be a text string containing the C code required to do
a particular IO action, for example. (+) isn't an abstraction in the
same sense, it *is* the "action" itself. (+) is the actual value of
the function that will add two numbers together. A monadic value is an
abstract recipe that you can't actually use directly (you can only
combine them, and if you're lucky you can "perform" them once you're
done combining them, e.g. ST, but not IO).

> > 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.

Why would you? I really don't see where you would get that idea? If I
tell you that a function returns "a fruit", would you ask where the
fruit in your factorial program is? Probably not. Why would you go off
and take an analogy for monads and apply it to something completely
different and still think the analogy holds?
A function is *not* a recipe in this analogy, it's just a function
(which you hopefully should've covered by the time you get to monads.
Monadic values, and *only* monadic values (not functions!) are to be
viewed as analogous to real world cooking recipes in this analogy.
Functions shouldn't. If you start mixing things together it will get
confused, so just don't!

I don't think this is very difficult to understand, so if you still
don't get it, I think you're just going to have to read it again
because I can't explain it any better, and in my experience, newbies
tend to understand this analogy within seconds (maybe that's the
problem, you're not a newbie)...

Sebastian Sylvan
UIN: 44640862

More information about the Haskell-Cafe mailing list