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