On 2 Aug 2007, at 5:13 am, alpheccar wrote:
I think the problem is due to a few bad tutorial still available on the web and which are making two mistakes:
1 - Focusing on the IO monad which is very special ; 2 - Detailing the implementation. As a newie we don't care and we would prefer to see how to use monads rather than how to develop monads.
When you look at monads you see they can be used for controlling the evaluation order (list monad, error monad, IO monad). They can be used for side effects (IO, state monad). They can be seen as containers (list, Maybe). They can be used to provide a protected environment (tainting). So, it is difficult to see what they have in common. Of course, what they have in common is a set of algebraic laws : the monadic laws but it does not help to know it.
I think that a way to see monads (and a consequence of the monadic laws) is that monads are interpreters for domain specific languages.
And so on. But please, let's keep one foot in the real world if possible. Monads were invented to solve the "how do I do imperative programming in a pure functional language" problem. We teach schoolchildren how to add. They spend years counting and adding before we point out that x+y == y+x. Most people leave high school without EVER having to know that the whole numbers are a ring or what that means. When they DO learn that, the only way they can really make sense of it is to turn it back to front "a ring is a collection of things and operations that is rather like whole numbers". In order to get almost anything *done* in a Haskell program, you HAVE to learn about the IO monad. You can get an amazing amount of useful stuff done without EVER learning about any other monad at all. The IO monad gets in your face all the time. You teach the IO monad before anything else about monads because if you *don't* teach about that, if you delay it any longer than you have to, the students become convinced that you can't do anything useful in Haskell and lose interest in learning anything else about it. Focussing on the implementation? Well, I believe in giving my students the original papers. One of them is "How to Declare an Imperative". Telling the students about the implementation is *important* to *gain their trust*. There's magic in Haskell, but THIS isn't magic. I go over it again and again: ">>= acts like semicolon; it's all about sequencing." If you've read the Science of Discworld books you will be familiar with the phrase 'lies-to-children'. You DON'T tell them the full truth, because it would take a long time, confuse the marrow out of their bones, and leave them feeling this was masturbatory mathematics, not real programming, having no connection with real world interests. Once they are reasonably comfortable with the IO monad, you can introduce ST. Once they are reasonably comfortable with the use of ST for arrays, you can show them the axioms that are required for monads to work the way we expect. Once they have got *that*, you can then show them that Maybe is a monad in that we can define the operations in a useful way that also satisfies the axioms. Then we can go onto other monads, except that in a first course, there isn't time for that. But at least we haven't scared them off completely by telling them that monads are interpreters.