Ronald Guida wrote:

Here is the brief explanation I came up with:

...

Arrows and monads are abstract data types used to construct Domain Specific Embedded Languages (DSELs) within Haskel. A simple arrow provides a closed DSEL. A monad is a special type of arrow that creates an open DSEL by allowing users to embed arbitrary Haskel within it.

Is this an accurate explanation? I hate to feed a fire, but is "Domain Specific Embedded Language" a well-defined phrase, or is it just another example of linguistic cruft?

Neither. It's the latest buzzword, joining the likes of AOP and Generics. Haskell has an opportunity to ride the DSEL bandwagon, and like most such opportunities it can take her where she don't want to go. Ronald Guida wrote:

Also, is this a /useful/ explanation, or have I simply hidden the complexity by invoking the concepts of ADTs and DSELs?

It certainly has a nice spin. I've nominated you to the Monad Marketing Team already. -- View this message in context: http://www.nabble.com/Explaining-monads-tf4244948.html#a12140216 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Having just gone through all the tutorials and things (again but this time I think it stuck) the Haskell community is on the wrong track as far as teaching Monads to new programmers. If I were teaching addition and multiplication to children I wouldn't start with, "We'll begin by defining an algebraic structure named a "Group". From there we'll expand our concept to a "Ring" and "Field". A group is a set and a binary operator usually named "+" (or sometimes "*") such that...". No no no. You start with, "You all know how to count from one to 10. If we have 1 item and we 'add' another 1 item we have 2 items. We write this 1+1=2." The tutorials seriously need to step back and start with something like, "To enforce order of evaluation we evaluate closures* returning a defined type. The first closure will feed its result to the second which will in turn feed it's result to the third. Since the third closure can't be evaluated without having the results from the second and first (and thus they had to be evaluated earlier in time) we get a defined evaluation sequence. Here are some examples..." (* Even using the word 'closure' is scary for those not familiar with them.) Then, like "Monads For Functional Programming" (the paper that finally clicked Monads for me) you point out that evaluating all these closures returning a defined type in various ways form a structure (which you can then explain) and we can use that structure and change out the underlying effect(s) as needed. Now of course if your new programmer has the the necessary background you can throw them in the deep end. But don't do that to someone coming at the language from something like Java learned out of a business degree course. (My background is a CS degree with math minor and it still took two go-s at Haskell before I got as far as understanding what folks were talking about with Monads. Wish I had found Wadler's MFFP the first time around.) Where are the shallow end tutorials? (Don't get me wrong. The tutorials are good but there is also a place for the "learn-by-rote with lots of examples" ones too.) $0.02, -ljr PS - Not so much directed at Ronald's post but his was convenient to get me on my soapbox. Ronald Guida wrote:

My present goal is to understand monads well enough to be able to explain them to others. I wonder if it's possible to create a tutorial that explains monads well enough so that they just "make sense" or "click" for people. -- Lanny Ripple ScmDB / Cisco Systems, Inc.

On 8/14/07, Sebastian Sylvan wrote:

I like the very light weight analogy (which works for most practical uses of monads) that a monadic action is a "recipe"

Many introductory programming books present the idea of a program as a recipe. Here's a recipe for computing factorials: fact 0 = 1 fact n = n*fact (n-1) Where do monads come in? -- Dan

On 8/14/07, Sebastian Sylvan wrote:

On 14/08/07, Dan Piponi wrote:

...

Where do monads come in?

Well I would try to distinguish between code that we write to compute values, and values which represent monadic actions when coming up with analogies.

How would you make that distinction? At this point I can imagine students immediately thinking that my factorial program is a recipe and wondering why it doesn't involve monads. Either you distinguish between these things in a circular way using monads (no use when teaching monads in the first place) or you have some a priori distinction that you point out to students. -- Dan

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

Sebastian Sylvan wrote:

On 14/08/07, Dan Piponi wrote:

...

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!

As a mostly-newbie who is working on his own monad tutorial (bwah-hah-hah), I share Dan's confusion about your analogy. Teacher: "Monads are like recipes." Student: "Aren't functions like recipes, too?" Teacher: "Well, yes, but we're talking about monads now, not functions." That response doesn't help the student, because the student already knows about functions, and would probably understand monads a lot better if he or she knew how monads are *different from* functions. (Especially since, umm, isn't the ((->) a) data type a monad?)

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 wrote:

...

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

Dan Piponi, Tue, 14 Aug 2007 11:52:16 -0700:

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.

(+) is not a recipe, it is a chef. On the other hand, (return 5 :: State Integer) is a recipe. You need a chef, namely runState, to get your meal. Oh my, imagery can be so crazy. Malte

On 2007-08-14, Dan Piponi wrote:

On 8/14/07, Sebastian Sylvan wrote:

...

I like the very light weight analogy (which works for most practical uses of monads) that a monadic action is a "recipe"

Many introductory programming books present the idea of a program as a recipe. Here's a recipe for computing factorials:

fact 0 = 1 fact n = n*fact (n-1)

Where do monads come in?

Playing the devil's advocate here: Recipe is a reasonable description for imperative code ... because it's all in the IO monad. Not such a good mapping for functional code. (I don't think recipe is a good analogy for, say, the List monad, reader monads, etc.) -- Aaron Denney -><-

Look! You are doing it again! :) Does that paragraph even contain the word "Monad"? :) I'm aware a monad is an abstraction and as such it doesn't *do* anything. My point was along the lines that you don't need to know that your working in a field to be able to learn that 3/2 = 1.5 . -ljr Jeff Polakow wrote:

Hello,

There is clearly a problem with the Haskell/monad tutorials out there...

...

The tutorials seriously need to step back and start with something like, "To enforce order of evaluation we evaluate closures* returning a defined type. The first closure will feed its result to the second which will in turn feed it's result to the third. Since the third closure can't be evaluated without having the results from the second and first (and thus they had to be evaluated earlier in time) we get a defined evaluation sequence. Here are some examples..."

The style of this description is nice; however the description itself is wrong.

Monads DO NOT determine order of evaluation. Previous posts on this thread give several examples.

In lazy languages, data dependencies determine the order of evaluation. X must be evaluated before Y if Y depends upon the result of X. You can force the order of evaluation without using a monad just as you can have a monad which does not determine the order in which things get evaluated.

From the point of view of a programmer, a monad is simply a useful (higher-order) combinator pattern. All monadic code can be flattened by replacing occurrences of bind (>>=) with it's definition.

One general intuition about monads is that they represent computations rather than simple (already computed) values:

x :: Int -- x is an Int

x :: Monad m => m Int -- x is a computation of an Int

x :: [Int] -- x is a computation of an Int which can return multiplie values

x :: Maybe Int -- x is a computation of an Int which might fail (return Nothing)

x :: State s Int -- x is a computation of an Int which relies on, and returns (possibly modified) -- a value of type s. Note: State s Int is isomorphic to: s -> (Int,s)

x :: IO Int -- x is a computation of an Int which can interact with the outside world.

Return explains how to make a simple computation which returns a specified value. Bind explains how to use the result of a computation to compute something else.

-Jeff

---

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

-- Lanny Ripple ScmDB / Cisco Systems, Inc.

A very good point. I even knew that implicitly but wasn't thinking in those terms explicitly when writing up my first post and it does make a difference in how you view things. -ljr Jeff Polakow wrote:

Hello,

...

Look! You are doing it again! :) Does that paragraph even contain the word "Monad"? :)

Sorry. Your first paragraph led me to believe you were writing about monads.

...

I'm aware a monad is an abstraction and as such it doesn't *do* anything. My point was along the lines that you don't need to know that your working in a field to be able to learn that

3/2 = 1.5

I agree.

I think one of the problem with understanding monads comes from people mistakenly believing monads force an order of evaluation. This is a shortcoming of general Haskell tutorials which fail to convey that the order of evaluation is determined by data dependencies. If new programmers know that monads have nothing to do with forcing the order of evaluation when they start learning about monads, then maybe they will be less confused as they sort out what monads are actually used for.

-Jeff

---

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

-- Lanny Ripple ScmDB / Cisco Systems, Inc.

On 8/14/07, Jeff Polakow wrote:

One general intuition about monads is that they represent computations rather than simple (already computed) values:

x :: Int -- x is an Int x :: Monad m => m Int -- x is a computation of an Int

What's a "computation"? It seems to me that in a lazy language, x::Int represents a computation of an int, not an "already computed" value. x::[Int] is a computation that returns multiple values. x::(Int,Int) is a computation that returns a pair of values. x::() is a computation that returns nothing. x::Map a b is a computation that gives a way to associate values of type a with values of type b. Some of these are monads, some are not. What's the difference between them? Why are you calling certain values "computations"? -- Dan

On 8/14/07, Lennart Augustsson wrote:

You don't normally call x::Int a computation of an Int because there's nothing that distinguishes the value of the x from what it was before you computed it.

Can you spell out exactly what you mean by this?

So I prefer to regard x as a value (in a domain, of course). But for x :: (Monad m) => m Int there is something else happening

When someone uses the phrase "something else" it implies that we are talking about two things, a "something" and a disjoint "something else". For example, if x = [1,2,3] what is the "something" and what is the "something else"? What was the x "before [I] computed it" and how does it differ from its "value"?

This is just the terminology people use, not an absolute truth, so you're free to think it's wrong. :)

For something like this I prefer to think in terms of "useful" and "not useful". If you find the term "computation" useful, I might find it useful too. So I'm jealous as I can't figure out how to use it. :-) I'm not looking for a formal definition or anything like that. But I would like a reliable way to distinguish between things that are computations and things that are not. -- Dan

Hello,

On 8/14/07, Jeff Polakow wrote:

...

One general intuition about monads is that they represent computations rather than simple (already computed) values:

...

x :: Int -- x is an Int x :: Monad m => m Int -- x is a computation of an Int

What's a "computation"? It seems to me that in a lazy language, x::Int represents a computation of an int, not an "already computed" value.

This intuition for monads as "computations" is independent of operational semantics.

x::[Int] is a computation that returns multiple values. x::(Int,Int) is a computation that returns a pair of values. x::() is a computation that returns nothing. x::Map a b is a computation that gives a way to associate values of type a with values of type b. Some of these are monads, some are not. What's the difference between them? Why are you calling certain values "computations"?

Of course, the type [Int] denotes a value which is a list of Ints; additionally [Int] can be viewed as a value representing the nondeterministic computation of a single Int. Generally, the type Monad m => m Int can be viewed as a value representing the computation of an Int. However, I do not mean to imply that everything which can be viewed as a computation of something is a monad. In any case, this is only meant to be a general (i.e. high-level) intuition. BTW, this intuition was, more or less, the one used by Moggi when describing how monads can be used to describe denotational models for languages. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Hello,

On 14/08/07, Jeff Polakow wrote: Of course, the type [Int] denotes a value which is a list of Ints; additionally [Int] can be viewed as a value representing the nondeterministic computation of a single Int. Generally, the type Monad m => m Int can be viewed as a value representing the computation of an Int.

But thats not really right. What exactly m Int does /depends/ on m. It might represent 0 or more computations of Int, or computations of Int carrying some extra stuff around, or complex control logic about what the computation does when.

Perhaps the confusion is in the word computation. I'm using the word in an abstract sense. I do not mean the actual execution of Haskell code to produce a value. Thus, under this intuition: The type Int represents a value which denotes an Int. The type m Int denotes a value which is a single computation (for an unspecified notion of computation) of an Int. A specific computation of an Int might result in several, or zero, actual Ints (the list monad); a String or an Int (the Either String monad); the constant () (the trivial monad); ... The type Monad m => m Int cannot represent multiple computations of an Int. The type Monad m => [m Int] represents multiple computations of an Int (of course, any container type can be used in place of list). -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Derek Elkins wrote:

What people need to do is stop reading two page blog posts by someone who's "just got" monads and read the well-written peer-reviewed papers

I have taught many people to program in group settings and individually in my career. I have referred them to many tutorials. I have used many examples from tutorials I thought were useful. I can't recall a single time I've ever turned to a beginner and said, "And you really should brush up on the peer-reviewed papers to learn this part."

by the people who clearly know what they are talking about. Luckily, for monads applied to Haskell we have Wadler, a witty, enjoyable and clear writer/speaker. All of Wadler's monad "introductions" are readable by anyone with a basic grasp of Haskell. You certainly don't need to be even remotely an academic to understand them. I'm willing to bet that many people who say they don't understand monads and have read "every tutorial about them" haven't read -any- of Wadler's papers.

I'm confused. Are you praising Wadler or bashing the tutorials (or both)? *I* was carping about the tutorials (and even mentioned that Wadler was my breakthrough) so I suspect we are in violent agreement. -ljr -- Lanny Ripple ScmDB / Cisco Systems, Inc.

For what it's worth, the nature of Haskell is such that you do (at least currently) have to spend a lot of time reading research papers to understand what's going on. Maybe that will change sometime, but probably not soon. This ties in to the open-endedness of Haskell; I sometimes think that really understanding all of Haskell is like really understanding all of mathematics. This is frustrating, but it's also what makes the language so rewarding. I guess what I'm saying is: get used to it, it's not so bad. Mike Derek Elkins wrote:

On Tue, 2007-08-14 at 12:40 -0500, Lanny Ripple wrote:

...

...

What people need to do is stop reading two page blog posts by someone who's "just got" monads and read the well-written peer-reviewed papers I have taught many people to program in group settings and individually in my career. I have referred them to many tutorials. I have used many examples from tutorials I thought were useful. I can't recall a single time I've ever turned to a beginner and said, "And you really should brush up on the

Derek Elkins wrote: peer-reviewed papers to learn this part."

How about a book? You've never recommended a book? But even so, where did I say tutorial? The -are- good monad tutorials, they are just horribly out-weighed by bad ones. Further, having a tutorial as supplement to person-to-person education is totally different from trying to learn purely from tutorials. Also, what is wrong with papers or recommending them? Finally, how often have you been part of a community where the primary mode of documentation is a research paper...

...

...

by the people who clearly know what they are talking about. Luckily, for monads applied to Haskell we have Wadler, a witty, enjoyable and clear writer/speaker. All of Wadler's monad "introductions" are readable by anyone with a basic grasp of Haskell. You certainly don't need to be even remotely an academic to understand them. I'm willing to bet that many people who say they don't understand monads and have read "every tutorial about them" haven't read -any- of Wadler's papers.

...

I'm confused. Are you praising Wadler or bashing the tutorials (or both)? *I* was carping about the tutorials (and even mentioned that Wadler was my breakthrough) so I suspect we are in violent agreement.

I'm praising Wadler and bashing the good majority of monad tutorials, but not all of them. Mostly I'm pointing out an unreasonable aversion to reading papers, as if a paper couldn't possibly be understandable.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Conor McBride and Ross Paterson said it best in the introduction to their paper "Applicative programming with effects" [1]: "This is the story of a pattern that popped up time and again in our daily work,..., until the temptation to abstract it became irresistible. Let us illustrate with some examples." Translation: Unless you've broken your back hauling water by hand, you'll never truly "get" the utility (even joy) of installing plumbing. To help you speed through (but not skip over) this necessary hauling drudgery, we will show the movie of us doing it in fast forward, and ask you to make the leap of faith that the sweat dripping off our brows is real, not sprayed on to make us look impressive. The fatal flaw of all tutorials is that the easier they make things seem, the less visceral understanding of the importance and benefit the reader will have. So here's my 30-second monad meta-metaphor: Monads are like wrapping paper, so the surprise isn't spoiled before Christmas. Every present can be wrapped, the paper doesn't damage what it covers, and there's no need to wrap it twice, it's no more opaque than wrapping it once. But you know better! You don't want to bother wrapping your presents. Your children promise not to peek until Christmas day anyway. After first, you have plenty of time to watch them. But as the holidays approach, you get busier, and pretty soon you have to choreograph your entire day just to divert their attention. It only takes one slip-up to ruin the surprise, so you spend a great deal of effort making this happen. Your mother (who has been down this route before with you) knows from experience that it is just easier to use wrapping paper, but you don't believe her. She's so old-fashioned and dogmatic! In a misguided attempt to be helpful, she whips out the dreaded Monad Tutorial Book of All Human Wisdom and explains the concept of Present Wrapping. The authors have PhDs in the science of concealment and compare the common properties of paper, boxes, sleight-of-hand, and one-way mirrors, but your eyes glaze over because you don't care about mirrors, you just have a present. Helpful friends share their war stories, but as you're not a bad parent like they are, you don't fall for their arrogant attempts to educate you and you point out how in each case their experience doesn't fit your needs. The most amazing thing in this metaphor is the strangely irrepressible joy that those who've mastered the art of present wrapping have to share their discovery with others. I guess some things are just too good to keep to yourself! Sadly, these tend to be the things you can't even give away without getting flak for it... :( Dan Weston [1] http://www.soi.city.ac.uk/~ross/papers/Applicative.html Lanny Ripple wrote:

Having just gone through all the tutorials and things (again but this time I think it stuck) the Haskell community is on the wrong track as far as teaching Monads to new programmers.

If I were teaching addition and multiplication to children I wouldn't start with, "We'll begin by defining an algebraic structure named a "Group". From there we'll expand our concept to a "Ring" and "Field". A group is a set and a binary operator usually named "+" (or sometimes "*") such that...".

No no no. You start with, "You all know how to count from one to 10. If we have 1 item and we 'add' another 1 item we have 2 items. We write this 1+1=2."

The tutorials seriously need to step back and start with something like, "To enforce order of evaluation we evaluate closures* returning a defined type. The first closure will feed its result to the second which will in turn feed it's result to the third. Since the third closure can't be evaluated without having the results from the second and first (and thus they had to be evaluated earlier in time) we get a defined evaluation sequence. Here are some examples..."

(* Even using the word 'closure' is scary for those not familiar with them.)

Then, like "Monads For Functional Programming" (the paper that finally clicked Monads for me) you point out that evaluating all these closures returning a defined type in various ways form a structure (which you can then explain) and we can use that structure and change out the underlying effect(s) as needed.

Now of course if your new programmer has the the necessary background you can throw them in the deep end. But don't do that to someone coming at the language from something like Java learned out of a business degree course. (My background is a CS degree with math minor and it still took two go-s at Haskell before I got as far as understanding what folks were talking about with Monads. Wish I had found Wadler's MFFP the first time around.) Where are the shallow end tutorials? (Don't get me wrong. The tutorials are good but there is also a place for the "learn-by-rote with lots of examples" ones too.)

$0.02, -ljr

PS - Not so much directed at Ronald's post but his was convenient to get me on my soapbox.

Ronald Guida wrote:

...

My present goal is to understand monads well enough to be able to explain them to others. I wonder if it's possible to create a tutorial that explains monads well enough so that they just "make sense" or "click" for people.

<snark> As you know, an arrow tutorial is like a wrapper around a monad tutorial, sort of like a container around it that can do extra actions with sufficient lifting. The appropriate higher-order function to convert monad tutorials to arrow tutorials will be left as an exercise to the reader. </snark> I'm becoming more and more convinced that metaphors for monads do more harm than good. From now on I'm going to describe monads as purely abstract entities that obey certain laws, and that _in certain instances_ can be viewed to be like containers, or actions, or donuts, or whatever. In other words, a monad is an abstract thing that can generate things that we can metaphorize, but it's pointless (point-free?) to try to capture the entire concept in a single metaphor. I'm reminded of a physics teacher who was having a similar problem explaining the concept of tensors, until he said that "a tensor is something that transforms like a tensor does!". So a monad is something that behaves like a monad does. Mike (who obviously hasn't had nearly enough coffee today) Dougal Stanton wrote:

On 14/08/07, Dan Weston wrote:

[snips another metaphor for monadic programming]

No offence to Dan, whose post I enjoyed. The concept of wrapping is as close a metaphor as we seem to get without disagreements. But this has brought me to a realisation, after Paul Erdos:

The Haskell community is a machine for converting coffee to monad tutorials.

In the spirit of the venture, I will now suggest that someone points out that they don't like coffee, and that I haven't allowed for arrow tutorials ;-)

Cheers,

D. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 2007-08-14, Michael Vanier wrote:

I'm reminded of a physics teacher who was having a similar problem explaining the concept of tensors, until he said that "a tensor is something that transforms like a tensor does!".

Which is silly. A tensor is a linear function of vectors and linear functions of vectors. That has implications about its transformation properties, and anything with those transformation properties can be used as a tensor, but this formulation gives the flexibility to say what happens when you're using different bases for different "slots". -- Aaron Denney -><-