On Thursday, March 28, 2002, 16:37 CET James B. White III wrote:
[...] I think the default definition of ">>" is just that, a default, and not a law.
I suppose, a >> b = a >>= \_ -> b is intended to be a law. This would mean that every redefined (>>) would have to obey this law.
[...] If it is a law, why are users given the power to change it!
For performance reasons, I would suppose.
Also, I think that the Report *specifies* the translation of "do" to ">>", not merely suggests it.
The report specifies certain identities and suggests to use these identities for translations into the kernel. If it is also a law that a >> b and a >>= \_ -> b are identical even with respect to laziness then, I think, a conforming Haskell implementation could use the latter instead of the former to realize do expressions. But I would prefer implementations using (>>).
[...] ">>" should no longer be a class function with a default value that can be changed; it should be syntactic sugar built into Haskell, like "do" notation.
It shouldn't be syntactic suger but at most an operator which does not belong to the monad class. One could define (>>) just as an ordinary function instead of a class member.
[...]
By the way, why uses the report the complicated looking \_ -> b instead of just const b. Wolfgang