I've seen the analogy with "recipes" used before, but I think that you
need to be careful when you try to distinguish the analogy to monads
from the analogy to functions. The reason is that, in the one-of-many
ways that I view monads, a monad is just a high-order /function /that
abstracts away function composition. In particular, if I have an action
f, and an action g, I can think of them as recipes, because I can
combine them via f >>= g. It's only after I combine all of my actions
together that I apply the result to my input (via "run").
Well, that's just like function composition. In particular, if I have a
function f, and a function g, I can think of them as recipes, because I
can combine them via f . g. It's only after I combine all of my
functions together that I apply the result to my input.
-Paul
Sebastian Sylvan wrote:
On 14/08/07, Dan Piponi <[EMAIL PROTECTED]> wrote:
On 8/14/07, Sebastian Sylvan <[EMAIL PROTECTED]> 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)...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
