Ansley, Michael wrote:
> If a construct is ambiguous, then the behaviour should be undefined (i.e.:
> we can do what we like, within reason). If the user wants something
> predictable, then she should use brackets ;-)
>
> If 3+-2 presents an ambiguity (which it does) then make sure that you do
> this: 3+(-2). If you have an operator +- then you should do this (3)+-(2).
> However, if you have 3+-2 without brackets, then, because this is ambiguous
> (assuming no +- operator), this is undefined, and we can do pretty much
> whatever we feel like with it. Unless there is an operator +- defined,
> because then the behaviour is no longer ambiguous. The longest possible
> identifier is always matched, and this means that the +- will be identified.
>
> Especially with the unary minus, my feeling is that it should be placed in
> brackets if correct behaviour is desired.
When I first read that, I thought "can sign every word of that".
But suddenly realized that there are more buggy situations here:
consider a>-2. It is parsed as (a) >- (2). Even in original
Thomas Lockhart's version there is a bug: it parses a>-b as (a) >- (b).
So I decided to simply forbid long operators to end with minus. If you
think that it is right, here is the patch (today is my patch bomb
day :). It is to be applied *instead* my earlier today's patch.
Seems that it is the only more or less clean way to deal with
big operator/unary minus conflict.
--
Leon.