">>" and "do" notation

[Simon Peyton-Jones]

| 	> 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