| > I think the point that's being missed in this discussion
| > is that a monad is a n *abstract* type, and sometimes the
| > natural "equality" on the abstract type is not the same as
| > equality on representations. ... If we can give >> a=20
| more efficient
| > implementation, which constructs a better representation
| > than >>=3D does, that's fine, as long as the two
| > representations "mean" the same thing.
|=20
| Point taken, but I remain unconvinced. What comes out of the
| monad /isn't/ abstract; there's nothing to ensure that
| subsequent use respects the abstraction.
|=20
| That's true, of course. But *should* we insist that the=20
| programming language guarantee that abstractions are always=20
| respected? i.e. equivalent representations are always treated=20
| equivalently?=20
This is an interesting discussion but from the point of view of H98 I'm=20
interested in answering the following much narrower question:
what should be the desugaring of=20
do { e ; Q }
The current Report uses (>>) for this, and (>>=3D) for the "p <- e" =
case.
An alternative would be to use (>>=3D) for both.
I take it for granted that (>>) stays as an operation of class Monad:
several people have argued for this, and I have no intention of changing
H98 in that respect.
I take it for granted that if the Report says "use >>" then
implementations
should. So either GHC and Hugs have to change or the Report does.
So the question remains: what would be best for programmers:
A: the predictability that desugaring do-notation=20
uses only (>>=3D) and return, or
B: or the extra power of using (>>) for the no-patterns case?
If there are Good Reasons for having (>>) in the class, as several
have argued, then I guess we should go for (B). In that case the Report
would stay unchanged, and the impls would have to change. I also
thought that James's analogy of (-x) translating to (negate x) and not
to (0-x) was a good one.
I originally favoured (A) but I'm happy to go with (B).
anyone disagree?
Simon