I was thinking that if the changes are not too big, I would prefer to change 
for a good solution.

Stef

>>>>> 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
>> 
> 
> Oups, wrote to fast !
> 1--2 now compiles 1 - (-2) for obvious backward compatibility reasons
> (1...@-2) in batch mode (you import or recompile code).
> But it request disambiguation in interactive mode.
> 
> If I would adopt Igor strategy that I like better, then I would break code.
> I want smooth transition.
> 
> Nicolas


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

Reply via email to