Let us look inside Parser:

$- except as first binary character is forbidden in Scanner>>xBinary
Thus '1 +- 2' will scan successive tokens (1) (#+) (#-) (2).
This will be parsed with Parser>>messagePart:repeat:
Then Parser>>primaryException will gather (#-) (2) into (LiteralNode value: 
-2)

Without a space  '1+-2' will scan same 4 tokens (1) (#+) (#-) (2), and result 
will be the same.

However, inside literal quotes, space are significant in current 
implementation:
#(1 - 2) will answer (Array with: 1 with: #- with: 2),
#(1-2) will be scanned and parsed into (Array with: 1 with: -2).

Concatenating - and 2 as a single token occur in Scanner>>scanLitVec if and 
only if char following - is a digit...

I know how to change this:
- move token concatenation from #scanLitVec to #scanToken
- remove #- handling in #primaryExpression
- remove limitation in #xBinary

But then, this will change semantics of #(1--2) that will be parsed #(1 #'--' 
2) instead of #(1 #- -2).
We can also make a special handling in xBinary and not groke last - when 
immediately followed with a digit, and raise a Warning exception with 
defaultAction doNothing, but wich could be caught in Parser to warn user of 
possible ambiguity if interactive...

Thus we would keep most compatibility with current implementation.

What do squeakers think of this change ?

Nicolas


Le Samedi 13 Mai 2006 02:36, Dan Ingalls a écrit :
> Well, the *idea* was that you should not need spaces, and St-76, borrowing
> from APL, had a different character for the semantically different
> high-minus sign for negative literals, so this was not a problem. 
> High-minus bit the dust with the ascii changes of St80 thus necessitating a
> space before negative literals that follow binary messages.
>
> >Sorry cannot find the thread which started this discussion,
> >but it seems i cannot have some binary selector with minus sign last.
> >
> >For example, i can compile
> >    Compiler evaluate: 'nil -+ nil'
> >Or
> >    Compiler evaluate: 'nil -/+ nil'
> >
> >But i cannot compile
> >    Compiler evaluate: 'nil +- nil'
> >nor
> >    Compiler evaluate: 'nil +/- nil'
> >
> >I understand that eventually some expressions might be ambiguous like
> > 1+-2 that can be interpreted as (1) + (-2) or (1) +- (2)
> >But such ambiguity could raise an error or warning,
> >and in most case, spaces will help disambiguating:
> > 1+-   2 would be (1) +- (2)
> > 1+   -2 would be (1) + (-2)
>
> Agreed.
>
> >Funny, in current 3.9 spaces are ignored:
> >i have '1 +-   2' interpreted as (1) + (-2)
> >
> >I cannot even write 1 +-+ 2, though no ambiguity lie there...
>
> Agreed.
>
> >I guess all this is very squeak specific
>
> I don't know, but it ought to be fixed.
>
> 	- Dan