Monads

[Jerzy Karczmarczuk]

Ashley Yakeley comments:
> 
> Jerzy Karczmarczuk wrote:
> 
> >Monads are *much* more universal than that. They are "convenient patterns"
> >to code the non-determinism (lazy list monads), to generalize the concept
> >of continuations, to add tracing, exceptions, and all stuff called
> >"computation" by the followers of Moggi. They are natural thus to construct
> >parsers. Imperative programming is just one facet of the true story.
> 
> Perhaps, but mostly monads are used to model imperative actions. And
> their use in imperative programming is the obvious starting point to
> learning about them.

"Mostly" is very relative. The real power of monads is their universality.
This "modelling of imperative actions" is just a way to hide the State,
which in IO is rather unavoidable. But in my opinion it is rather
antipedagogic to introduce monads in such a way to beginners.

"Obvious starting point"? My goodness, but this is selling a black, closed  
box, which smells badly (imperatively) to innocent souls. People see then
just 
  do
     rubbish <- rubbish
     more_rubbish

and don't know anything about the true sense of return, of the relation of
<- to >>=, and finally they can use ONLY the IO Monad, nothing else. 

They start posing questions what is the difference between
 a <- b
and
 let a = b ...

and they get often ungodly answers to that, answers which say that the
main difference is that <- "executes side-effects", and let doesn't. It
choked me a bit. (Was it on comp.lang.functional, or on one of Haskell
lists?)


My philosophy is completely opposite. Introduce Monads as a natural way
of chaining complex data transfer and hiding useless information, and when
the idea is assimilated, then pass to IO. I begin usually with Maybe, then
with backtrack Monad, and some simple State Transformers. Then, the students
can grasp the Wadler's style slogan "Monads can Change the World".

Oh, well, all teaching approaches are imperfect.


Jerzy Karczmarczuk
Caen, France