On 12/07/2009 22:32, hask...@henning-thielemann.de wrote:
On Tue, 7 Jul 2009, hask...@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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
