">>" and "do" notation

[James B. White III (Trey)]

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