Proposal: change to qualified operator syntax
marlowsd at gmail.com
Wed Jul 8 04:27:09 EDT 2009
On 07/07/2009 16:58, haskell at henning-thielemann.de wrote:
> Adding to an old thread:
> I like to note that I'm against this proposal. The example given in
> 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.
More information about the Haskell-prime