2010/2/24 Igor Stasenko <[email protected]>:
> On 24 February 2010 09:25, Stéphane Ducasse <[email protected]> wrote:
>> After the lengthly discussion about the fact that Smalltalk implementation 
>> is a balkan region
>> (cf "what Pharo/squeak do not parse 16rFF)
>>
>>> 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.
>>
>>
>> I was wondering what do we do with that kind of changes.
>>        Is it useful?
>>        what is the end user case?
>>        what are the binary operators that we could invent with -~- -| -@
>>        nicolas do you have a case in mind?
>>        what VW people use it for?
>>
>> Now do we want this in pharo?
>> What is the cost?
>> Impact / broken code?
>>
>
> Huh? I am always assumed that binary selectors parsed in greedy
> manner, which means that if parser found the start of
> binary selector, it scans forward for following characters which can
> be part of selector, without exceptions, like '-' char..
>

This is precisely the reason I want to change this Behaviour for long.
It was an arbitrary, un-necessary limitation. Like Igor, I prefer uniformity.
The fact that VW did it influenced my decision to act.

> so,
> 1--2  should ALWAYS mean:   MessageSend receiver: 1 selector: #'--' argument: 
> 2
>
> and if you want an unary minus, you should put the white space or braces:
> 1 -- -2
> 1 -- (-2)
>

And this is precisely how things work now in trunk.
Beside, I forbid (-    2) which was authorized more accidentally than
intentionnally IMO.

Nicolas

>
>>>
>>
>> Stef
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to