Simon,
Thanks for summarizing the arguments about qualified operators. I
continue to be a strong advocate of this approach. IMO, we either have
to do this, or disallow . (dot) as an operator, and I think you are
right that it is too late to do the latter.
In the proposed implementation of this change, you say:
Prelude.(>>=) has to be a single lexeme, because there's no way to
lift the syntax of qualified names into the context-free grammar. So
this forces us to move the syntax for parenthesized operators and
`..` down to the lexical syntax
with the consequent behavior that `---` and (---) are not dual.
Can you regain duality by *also* providing a definition of `---` and
(---) at the level of the context free grammar?
John
John Launchbury | galois | (503)626-6616 x104
On Jul 9, 2009, at 4:22 AM, Simon Marlow wrote:
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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
