On 8/14/07, Sebastian Sylvan
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