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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
