Proposal: change to qualified operator syntax

[Simon Marlow]

On 12/07/2009 22:32, haskell at henning-thielemann.de wrote:
>
> On Tue, 7 Jul 2009, haskell at henning-thielemann.de wrote:
>
>> 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.
>
> Should the consistency with operator section also be added as 'cons' to
> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
> ?

So correct me if I'm wrong; the point you're making is:

              left section  right section   prefix
unqualified  (+ 1)         (1 +)           (+)
Haskell 98   (M.+ 1)       (1 M.+)         (M.+)
proposed     (`M.(+)` 1)   (1 `M.(+)`)     M.(+)
    or(*)     (M.(+) 1)     (flip M.(+) 1)

(*) only if precedence isn't important, e.g. not in cases like (`M.(+)` 
x `M.(*)` y).

Cheers,
	Simon