Proposal: change to qualified operator syntax

[Simon Marlow]

On 08/07/2009 23:06, kahl at cas.mcmaster.ca wrote:
> 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.(>>=)`

You don't *have* to write that, you can use the prefix form.  The 
argument that this proposal makes is that when you have to qualify an 
operator, it has lost most of the advantages of being infix.

> . 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! ;-)

Dot is a particularly troublesome character, owing to the decision to 
use it for qualified operators back in Haskell 1.3.  It's really too 
late to change that now, sadly.

> 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.

It does begin with a `, just like `Data.List.map`, or `fmap`.  So in 
that sense it is more like an infix operator than Prelude.>>=.

Anyway, thanks for all the comments in this thread.  I've tried to 
summarise the pros/cons on

http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators

Please let me know if I've missed anything.  The committee will review 
the arguments when we make final decisions.

I realise this change is not a clear-cut win.  So few things are.  It's 
a question of balancing the advantages against the disadvantages, and 
reasonable people are very likely to differ.

Cheers,
	Simon