Proposal: change to qualified operator syntax

[kahl at cas.mcmaster.ca]

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