RE [Haskell-cafe] Monad Description For Imperative Programmer

[ok]

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.