Simon Marlow replied to Henning Thielemann: > Prelude.>>= just doesn't look like an infix operator. The point of > infix operators is that they are a lightweight notation, but they lose > that advantage when qualified. The qualified operator proposal gives > you a nice rule of thumb to rely on when parsing code in your head: if > it begins with a letter, it is not infix. The advantages of this > shouldn't be underestimated, IMO.
Actually, I am another supporter of qualified infix operators. Is see on > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators that with the new proposal, I would have to write `Prelude.(>>=)` which in my opinion only asks for extension of the backquote symtax to arbitrary epressions, like `zipWith (+)` . I frequently run into situations where that would be extremely useful. > the M.. M... M.... debacle I don't think that problems arising from a single character should outlaw a whole lexical category. Better outlaw that character! ;-) The QualifiedOperators page also says: | You might argue that it is inconsistent to allow `(+)` but not allow | (`plus`), but the justification is simply that (..) and `..` are not | dual in this design. I would indeed argue that they should be dual. Back to the original argument: > Prelude.>>= just doesn't look like an infix operator. I think that `Prelude.(>>=)` doesn't really look like an infix operator either. If nobody else finds the time to do it, I'll hack lhs2TeX some day to generate a suscripted presentation, somewhat like |>>=|_{|Prelude|} from whichever variant will be legal at the time, and if the choice is among these two variants, I'd much prefer to type Prelude.>>= in my source code. Wolfram _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
