[Haskell-cafe] Monad Description For Imperative Programmer

[Alexis Hazell]

On Thursday 02 August 2007 15:57, ok wrote:

> It all depends on what you mean "make sense to".
> I can tell my student that (an instance of Monad) is a type constructor
> applications of which support certain operations that must satisfy
> certain operations.  They can memorise that.  But it remains meaningless
> noise to them.  What matters is not what monads *ARE* but what they are
> *FOR*. Why should anyone care what monads are until they know why monads
> matter?

Well, i would argue that people learning Haskell come to quite quickly 
appreciate that these 'monad' things are very important in Haskell; that they 
have to learn about them in order to perform IO and maintain state[1]; and 
that it's for those reasons at least that they matter. In my experience, many 
programmers - including myself! :-) - then try to get their head around what 
a Haskell Monad "is", and start asking questions of more experienced 
Haskellers, trying to get some sense of a possible answer.

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.)

This is why i feel it's important to provide an agreed-upon minimalist 
definition of a Monad - it can serve as a /correct/ starting point (to be 
elaborated on, of course - as Claus did), rather than forcing the programmer 
new to Haskell to /guess/ what a Monad might "be". We keep trying to suggest 
that Monads aren't really that scary, but the fact that we can't seem to 
agree upon a straightforward definition of what a Monad "is" belies that - i 
feel it tends to convey that in fact Monads /are/ a very complex concept, 
that asking what Monads are is like asking what God is or something. :-P And 
in my opinion, feeling that a given topic is overwhelming complex can become 
a block to further learning.


Alexis.

[1] Yes, they're obviously used for many other things besides those two 
things; but it's these two cases that are often of most interest to 
programmers coming from a non-functional background.