I am certain that was not the intention of the authors. So one possibility is to change the second line to read
do {e;stmts} = e >>= (\ _ -> do {stmts})
and that is what I *propose* to do.
However, James implies that in his monad (>>) has a different meaning than its usual one, and Haskell 98 allows that because (>>) is one of the class operations (not a good design choice I think). I'm quite reluctant to make the meaning of do-notation dependent on such differences.
I disagree. Hugs should be changed, not the report. In my opinion (>>) is a class operation, because there may be more efficient implementations of (>>) than the default one (\x y -> x >>= \_ -> y). The do notation should profit from a more efficient implementation. I do think that James steps on very dangerous ground if his implementation of (>>) is semantically different from (\x y -> x >>= \_ -> y). This semantic equality is a law of the monad class, that users expect to hold. However, the language (implementation) cannot enforce it; in particular, compilers cannot use such laws for optimisations. The programmer has the freedom to break such laws. The situation is similar with classes such as Eq and Ord. You expect x /= y == not (x == y), but it is not enforced. Actually, the report currently doesn't say that the given default definitions are laws which are expected to hold (except where a comment says otherwise, see class Enum). I think such a statement should be added to the report. Happy Easter, Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767