Do-notation

[Olaf Chitil]

> 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