Do-notation

> 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