Proposal: change to qualified operator syntax

kahl at kahl at
Wed Jul 8 18:06:30 EDT 2009

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


that with the new proposal, I would have to write


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


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


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.


More information about the Haskell-prime mailing list