
Dan Piponi wrote:
On Dec 3, 2007 1:09 PM, Denis Bueno
wrote: I don't think I can conclude that there are *no* reasons to teach the do-notation first. I just think that it is more instructive to teach it later.
It's standard in mathematics teaching, when introducing a mathematical structure X, to ensure that students have the knowledge to understand an example of X before they see the definition of X. So students won't study groups before they've met the integers, they won't study fields before they've met the rationals, and they won't study topology until they're familiar with the real line. Not just met them either, usually they've usually completely internalised the examples before moving onto the general structure.
Right.
The problem with monads is that students have never knowingly met an example of a monad before.
When one learns about Groups one hasn't met them /knowingly/ before, either. It may be that one has learned the laws that govern arithmetic; but it is not at all clear why one would want to look at one of the operations in separation, i.e. what the generality of the concept might be good for. This becomes clear only after having seen examples of a group whose elements are /not/ integers.
If you teach them do-notation for IO without monads, and they get completely familiar with it (which (1) I claim is easy:
http://sigfpe.blogspot.com/2007/11/io-monad-for-people-who-simply-dont.html
and (2) is inevitable if they want to see the output of their programs) then when they come to learning about monads in general they'll have an example they don't even have to think about.
I don't buy this. As has been noted by others before, IO is a very special case, in that it can't be defined in Haskell itself, and there is no evaluation function runIO :: IO a -> a. I'd rather use a simple example like Maybe (modeling failure as an effect). It can be completely understood even as a beginner, and is non-trivial enough to demonstrate the utility of the concept 'monad'. Cheers Ben