On 02/08/07, Alexis Hazell
It's at this point that i feel there's an issue. Haskell Monads are used FOR many many things. And rather than get to the core of what a Monad is, many people provide two or three motivating examples - examples which merely serve to show /some/ of what Monads are about, but which will lead astray any person who incorrectly assumes that these two or three examples constitute the totality of the Monadic universe, and who makes inferences about Monads accordingly. (To me, the notion that a Monad is merely a kind of loop is an example of this.)
I agree with this very much. Monads are used for a great deal of things, some of which seem related (IO/State, []/Maybe) while others are utterly disconnected. Simon Peyton Jones has jokingly said that "warm fuzzy things" would have been a better choice of name. In seriousness, though, I think the exact name is not the problem. I would suggest that *having a name* is the problem. In imperative programming there are many idioms we would recognise. Take the "do something to an array" idiom: for (int i = 0; i < arr.length; i++) { arr[i] = foo(arr[i]); } This is a pretty obvious pattern. Some might say it's so obvious that it doesn't need a name. Yet we've got one in functional programming because we can. Without higher-order functions it's not possible to encapsulate and name such common idioms. It seems a bit superfluous to name something if you can't do anything with the name. But with higher-order functions we *can* encapsulate these ideas, and that means we *must* name them. Add to that the insatiable mathematical desire to abstract, abstract, abstract... Intuitively it seems that monads are similar, except the instances are much less obviously connected. It's easy to see the connection between State and IO. But those two to []? Do I have an suggestions? Well, maybe the right way would be to do as we do with map and fold, etc: show the explicitly recursive example, then generalise. So, show how we could we would thread state in Haskell, or how we would do optional (Maybe-style) values, then generalise, *slowly* coalescing the more similar monads first before reaching the 'top' of the monadic phylogenetic tree. Hmm, I can see that previous paragraph is not as clear as it could be. But anyway: has anyone used this approach before? Cheers, D.