Proposal: change to qualified operator syntax

[Simon Marlow]

On 07/07/2009 16:58, haskell at henning-thielemann.de wrote:
>
> Adding to an old thread:
> http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html
>
> I like to note that I'm against this proposal. The example given in
> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
> namely [Red..] can be easily resolved by adding a space, thus [Red ..].
> I use qualified operators occasionally, since I use NumericPrelude and
> thus have to import some things from Prelude in a qualified way. As
> there will appear more and more infix operators in libraries along with
> more name clashes (e.g. recently discussed List.++ and Monoid.++),
> qualified operator names will become not so uncommon. Of course, to keep
> the spirit of infix operators, you will better define custom operators
> locally, but this is only reasonable if you use an infix operator more
> than once.
> The current syntax is also in a way consistent, since e.g. (+) coincides
> with a two side operator section, which is no longer true with the new
> proposal. Also (...) and `...` are dual, which is a nice property.


This proposal cleans up some nastiness in the lexical syntax.  For 
example the M.. M... M.... debacle.  How many lexemes in each of those? 
in Haskell 98 it's 1, 2, and 3 respectively, whereas with the qualified 
operator proposal they are all 2 lexemes.

Yes, you can add spaces to make [Red ..] work.  But why should you have 
to, when [1..] works without a space?

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.

Cheers,
	Simon