Re: Just for your fun and horror

["C.Reinke" <C.Reinke@ukc.ac.uk>]

> `return' in Haskell vs `return' in C,...

Unless you're one of Asimov's technicians of eternity, it is a bit
difficult to change the history of programming languages, and assuming
that the students pay for the opportunity to learn, you can't really
fire them either.. but I agree with Mathias' suggestion to go from the
specific to the general. 

Before anyone complains that abstract and generalised concepts are so
much more important and powerful that specific and simplified instances
- if you believe this, you will also agree that giving students a
chance to learn the general process of abstraction for themselves is more
important and empowering than teaching them some specific abstractions.

(I'm not sure whether it is even possible to reach all students in
 a course, but I will certainly not recommend to give up trying;-)

One way to look at the problem is that some of your students have 
concrete experience with `return' in different contexts, and that
Haskell tries to make different things look similar here. You say
"we worked with monads for several weeks" but, you being yourself,
this was probably at a fairly abstract and general level, right?

My suggestion is to give your students some concrete experience to
counter the one they bring into your course, by introducing the
abstract monads via an intermediate step of concrete representations.

As you're teaching programming language implementation anyway, why not
have an algebraic datatype with return and bind *constructors*,
together with some explicit *interpreters* (plural) for the language of
structures built from those constructors (even as student exercises)?

Perhaps we can gain a better understanding of the student perspective
if we compare the situation with lists or other data structures:  do we
start teaching their folds and the fold-representation of data
structures right away, or do we start with concrete intermediate
structures, and move on to folds and deforestation later?

Of course, with a concrete representation of monads, it is difficult to
hold up the law, so after this intermediate step (in which students get
their hands on `return' et.al., and in which interpreters can interpret
`return a' in any way they please), one can move on to an abstract data
type of monads. After all, that's what abstract data types are there for.

Hth,
Claus