Le Lundi 15 Mai 2006 23:31, Stephan Rudlof a écrit :
> Hello All,
>
> I've just digged into
> NCITS J20 DRAFT December, 1997 33 of ANSI Smalltalk Standard revision
> 1.9; in short:
> - 'White space is allowed between the '-' and the <number>' for a
> numeric literal; and
> - 'If a negative <number literal> follows a binary selector there must
> intervening white space.'
>

Very nice, but i just wonder how many Smalltalk are ANSI?
ST-80 no, VW3,5,7 no...
 * no - as second binary character, no space enforced
 * no space allowed between - and number
Squeak3.9 no... 
 * no - as second binary character, no space enforced
GNU Smalltalk version 2.1.9 no...
 * no space allowed between - and number
VA, Smalltalk-X, Dolphin, any other ?

> So your example
>
> >>> On 13.05.2006 02:10, nicolas cellier wrote: nc>... nc> Funny, in
> >>> current 3.9 spaces are ignored: nc> i have '1 +-   2' interpreted
> >>> as (1) + (-2)
> >>>...
>
> is totally legal,

No, it should be interpreted (1) +- (2).
You must force a space between binary selector + and negated number -  2
But (1 +  -  2) should be interpreted (1)+(-2)

> but 
>   x+-1
> should not be parsed as
>   (x) + (-1)
> . I'm interpreting the standard in this case - at least I think it can
> be interpreted this way (see below for the definition of binary
> operators) - as to parse it as
>   (x) +- (1)
> , +- being a binary selector.
>
> We should follow the standard IMO, this means to allow
>   x+-1
> (here I have changed my mind after looking into it). In spite of this I
> think it is not a good style to omit spaces here (and it gives a MNU
> later, if +- is not defined)...
>
> For points like
>   0 at -1
> this could give the workaround of defining
>   @-
> as operator (and @+ , too) much sense, because after the standard 0 at -1
> could be parsed as
>   (0) @- (1)
> . Moreover a compile warning - 'Please insert spaces! This will be
> parsed as ...; is this your intention?' or so - would make sense then
> (since the extra message send here decreases performance).
>

If we go for it, that's easy to implement, just have to change xBinary.
And we MUST also emit a warning in interactive parser.
Now, we're taking the compatibility risk if we follow ANSI...
@- at least is a necessary guard indeed...

I'am still in favour of compatibility, but ANSI has precedence over me i 
guess.

>
> Regards,
> Stephan
>

Nicolas