I recently discovered that Hugs converts "do" notation as follows. do {e;stmts} = e >>= \_ -> do {stmts} To me, this is inconsistent with the definition given in the Haskell 98 Report. do {e;stmts} = e >> do {stmts} It "hard wires" the default definition of ">>" into "do" notation. If you provide your own definition of ">>", which is completely legal in Haskell, the "do" translation in Hugs disagrees with the definition in the Report. In other words, the following two statements produce different results. do {e;stmts} = e >>= \_ -> do {stmts} do {e;stmts} = e >> do {stmts} When I reported this as a bug, I got responses stating that the definition of "do {e;stmts}" in the Report is merely a suggestion, and that the default definition of ">>" in the "Monad" class is a law of Monads and should not be redefined in instances. I strongly disagree with these responses. I think the default definition of ">>" is just that, a default, and not a law. This view is consistent with every other default definition in a class; it is there for convenience but may be redefined. If it is a law, why are users given the power to change it! Also, I think that the Report *specifies* the translation of "do" to ">>", not merely suggests it. This is the only interpretation that makes sense to me. The above claims---that the contents of the Report are mere suggestions and that default definitions are laws---baffle me. I beg the community to reassure me or enlighten me. If my thoughts are wrong, then I assert that the Report needs revision. ">>" 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. Let me just restate my argument for emphasis: a Monad instance should be able to define its own ">>" operator, and "do" notation should honor this redefinition! -- James B. White III (Trey) Center for Computational Sciences Oak Ridge National Laboratory whitejbiii@ornl.gov