On 08/07/2009 23:06, k...@cas.mcmaster.ca wrote:
Simon Marlow replied to Henning Thielemann:
> 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.
Actually, I am another supporter of qualified infix operators.
Is see on
> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
that with the new proposal, I would have to write
`Prelude.(>>=)`
You don't *have* to write that, you can use the prefix form. The
argument that this proposal makes is that when you have to qualify an
operator, it has lost most of the advantages of being infix.
. I frequently run into situations where that would be extremely useful.
> the M.. M... M.... debacle
I don't think that problems arising from a single character
should outlaw a whole lexical category.
Better outlaw that character! ;-)
Dot is a particularly troublesome character, owing to the decision to
use it for qualified operators back in Haskell 1.3. It's really too
late to change that now, sadly.
Back to the original argument:
> Prelude.>>= just doesn't look like an infix operator.
I think that
`Prelude.(>>=)`
doesn't really look like an infix operator either.
It does begin with a `, just like `Data.List.map`, or `fmap`. So in
that sense it is more like an infix operator than Prelude.>>=.
Anyway, thanks for all the comments in this thread. I've tried to
summarise the pros/cons on
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
Please let me know if I've missed anything. The committee will review
the arguments when we make final decisions.
I realise this change is not a clear-cut win. So few things are. It's
a question of balancing the advantages against the disadvantages, and
reasonable people are very likely to differ.
Cheers,
Simon
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
