| > 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
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
