Do-notation

[James B. White III (Trey)]

Simon Peyton-Jones wrote:
> However, James implies that in his monad (>>) has a different meaning
> than its usual one, and Haskell 98 allows that because (>>) is one of
> the class operations (not a good design choice I think).   I'm quite
> reluctant to make the meaning of do-notation dependent on such
> differences.  James, can you convince us that doing so would be a good
> idea?

I didn't see this before sending off my previous rant. My apologies.

Having separate definitions for ">>=" and ">>" is more flexible. With
the definition of a default for ">>" in the Monad class, having them
separate is no less convenient. More flexible, no less
convenient---where is the design flaw? I thought it was a design
triumph, fully in the spirit of elegance I associate with Haskell. 

Are there Monad laws that this breaks? If not, why impose an unnecessary constraint?

Let me describe my practical motivation for a separate definition for
">>". I am experimenting with using Haskell to build program generators
for embedded domain-specific languages. The goal is to generate
high-performance Fortran codes from high-level specifications.

I am using a Monad to hold the state of the generation. One thing
maintained in the state is a list of declared variables and a list of
busy, or in-scope, variables. The generator automatically adds variable
declarations as needed.

By differentiating between monadic statements that return an argument
(>>=) and those that don't (>>), the generator can easily determine when
variables go out of scope. Within the definition of ">>", it can free
these variables (in a logical, not physical, sense) to be reused. This
is critical because it allows me to generate code using large temporary
arrays efficiently.

As far as I can tell, this use of ">>" breaks no monad laws.

In Hugs, it works fine if I use ">>" directly instead of "do". For the
aesthetic acceptance of my user base, I need it to work with "do" notation.

-- 
James B. White III (Trey)
Center for Computational Sciences
Oak Ridge National Laboratory
whitejbiii@ornl.gov