On 07/07/2009 16:58, hask...@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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
