Hi Nicolas,

On Thu, Sep 24, 2015 at 5:01 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Then, given that negative numbers are correctly tokenified by the RBParser, I would remove that logic in Pharo's RBParser.

(From a front-end implementor point of view, I also would have no issue with someone specifying a negative literal as - (\s)* [0-9]+ either. There is so much silliness in your average language front-end anyway).

My grief was the interpretation of literal arrays: #(1 - 2) is currently not #(1 -2), so if space is gobbled at tokenization, that's a semantic shift...
Do we want to keep #(1 - 2) or shall we force some more pedantic #(1 #- 2)?

We should keep #(1 - 2) provided it is interpreted as #(1 #'-' 2).�� The # tags are noisy (if not ugly) and have never been necessary for literal symbols inside arrays. ��-2 is quite different from - 2.

Also why do you think this means?

�� 1.0

Given that this means two different statements

�� nil.nil

IMO, . as a statement separator should be followed by whitespace to eliminate this ambiguity. ��i.e. nil.nil would be a syntax error, and nil. nil would be acceptable.�� This opens up the use of . in selectors to do cool things like the old multiple inheritance syntax where one could do directed sends such as super Dictionary.at: key if in a subclass with multiple superclasses and wanting to disambiguate which of multiple superclass implementations one wanted to invoke.

��

��
What is the state of RBParser in Squeak about that?

RBParser is not in trunk, it's an add-on.
No idea which/where is the latest Squeak-compatible version...
��

Thierry

2015-09-24 12:03 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Oh, and I suspect an instability in the numbering of squeak-dev archive...
The reference thread is (today) http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/103684.html

2015-09-24 11:39 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
A space used to be accepted between minus sign and number in old versions of Squeak compiler (before 2010)
But I doubt this was decided on purpose.
IMO it was more a side effect of the implementation, which had messy corners
(the fact that the tokenizer did produce two tokens $- and positive number)

I would add that this was undocumented, dialect specific, and a false good idea letting newbies think that they can use unary prefixed operators...
There is no such thing in the language.

Oh, and this even has changed in Squeak a few years ago:

-------------------------------------------------------

http://source.squeak.org/trunk/Compiler-nice.120.mcz

==================== Summary ====================

Name: Compiler-nice.120
Author: nice
Time: 23 February 2010, 5:14:44.049 pm
UUID: 9429cc05-281b-484e-94c2-bd0baf4f5230
Ancestors: Compiler-nice.119

Authorize - at any position in binary selectors (like VW 7.7)
See http://bugs.squeak.org/view.php?id=3616
Address the problem of compiling 1@-2 with following strategy:

If compiler is non interactive, then compile with backward compatibility 1 @ (-2).
If compiler is interactive, propose a menu to disambiguate and insert a proper space.
1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2
1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2

Warning: Squeak did understand (1@-�� 2) as (1 @ (-2))....
I didn't do anything to support this vicious Squeakism, and by now the semantics are change.

2015-09-24 9:25 GMT+02:00 Cl��ment Bera <bera.clement@gmail.com>:

2015-09-24 8:19 GMT+02:00 Peter Uhn��k <i.uhnak@gmail.com>:
>�� - 250 * 1.5 returns -2.25

why is this valid syntax?

It should not. RBParser bug. This is not valid Smalltalk syntax. As Ben showed similar cases raise an error but this one generate incorrect compiledMethod instead.
��

On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
RBParser parseExpression: '-250 * 1.5' => "RBMessageNode(-250 * 1.5)"
RBParser parseExpression: '- 250 * 1.5'�� =>�� "RBMessageNode(*1.5 * 1.5)"

RBParser parseExpression: '250 * -1.5'�� =>�� "RBMessageNode(250 * -1.5)"
RBParser parseExpression: '250 * - 1.5'�� =>�� MNU RBToken>>realvalue.

RBParser parseExpression: '-250'�� =>�� "RBLiteralValueNode(-250)"
RBParser parseExpression: '- 250' =>�� MNU RBToken>>realvalue.

So how significant should be the space between the negative sign and its number?

cheers -ben

On Thu, Sep 24, 2015 at 6:34 AM, Cl��ment Bera <bera.clement@gmail.com> wrote:
> RBParser parseExpression: '- 250 * 1.5'�� => Answers�� RBMessageNode(*1.5 *
> 1.5)
>
> Second expression looks correct.
>
> Hence RBParser bug.
>
> 2015-09-23 23:42 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
>>
>> debug it on the first one gives "MNU: receiver of "doSemanticAnalyisIn:"
>> is nil.
>>
>> Weird.
>>
>> On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
>>>
>>> Hi guys
>>>
>>> I think that this is quite bad that
>>>�� - 250 * 1.5 returns -2.25
>>>
>>> while
>>>
>>>�� -250 * 1.5 return 375
>>>
>>> stef
>>>
>>
>

_,,,^..^,,,_

best,��Eliot