I'd just like to add a brief note to what Claus has said: On 2003-10-06 at 19:48BST "C.Reinke" wrote:
[moved to haskell-cafe]
The odd is in the conceptual explanation. If I give a description of some f x = y function in Haskell I expect that some program f x is reduced to y and the result is given back (possibly printed). A good story to sell to students.
This is almost everywhere the case except for the IO monad.
indeed. Although, for the benefit of your students, you'll want to separate printing and reduction, even in the first case.
I think one of the causes of confusion here is that the interpreters (ghci and hugs) do something solely for the convenience of the user -- namely print out /values/ -- that has nothing to do with the execution of Haskell /programmes/. I don't think that the definition of the language has anything to say about the effect of evaluating an expression. You could imagine an interpreter that only permitted objects of type IO () (or IO t, but that would still be confusing) to be entered at the top level. It would be less useful, because it would respond to an input of 2+2 with a type error and you'd have to enter print $ 2+2 instead. Alternatively it might respond to 2+2 with "it:: Integer" and then you could enter "print it". Either of these would be less convenient to use, but would avoid that "(possibly printed)" above. If you remove the "(possibly printed)" and tweak a bit you get
[...] If I give a description of some f x = y function in Haskell I expect that some /expression/ f x is reduced to y and the result is given back. A good story to sell to students.
And I'd agree completely, but you can't output a value to a terminal, you have to output a sequence of characters, and to do that you have to observe certain conventions that have nothing to do with the value itself. Cheers, Jón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk