| > 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 | more efficient | > implementation, which constructs a better representation | > than >>= does, that's fine, as long as the two | > representations "mean" the same thing. | | 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. | | That's true, of course. But *should* we insist that the | programming language guarantee that abstractions are always | respected? i.e. equivalent representations are always treated | equivalently? This is an interesting discussion but from the point of view of H98 I'm interested in answering the following much narrower question: what should be the desugaring of do { e ; Q } The current Report uses (>>) for this, and (>>=) for the "p <- e" case. An alternative would be to use (>>=) 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 uses only (>>=) 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