About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Stéphane Ducasse
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?

>

Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Igor Stasenko
On 24 February 2010 09:25, Stéphane Ducasse <[hidden email]> 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..

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)


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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Lukas Renggli
> 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..

I checked in the ANSI standard. Igor is right:

== ANSI: 3.5.6 Numbers ======

  binaryCharacter ::= '!' | '%' | '&'' | '*' | '+' | ','' | '/' | '<'
| '=' | '>' | '?' | '@' | '\' | '~' | '|' | '-'
  binarySelector ::= binaryCharacter+

Binary selectors are method selectors that appear similar to
mathematical operators. A binary selector may be any length greater
than or equal to one. If a negative <number literal> follows a binary
selector there must intervening white space."

=========================

I somehow remembered the grammar differently and that the $- was only
allowed in the first position. This doesn't seem to be the case though
(any longer) :-/

I am not against changing the grammar to conform to ANSI and VW. I
think that would actually be a good move, even if it is probably not
really relevant in practice. I am however strongly against asking the
user to disambiguate an expression. The compiler should compile what
the user types, not guess what else he could have ment to say.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Nicolas Cellier
In reply to this post by Igor Stasenko
2010/2/24 Igor Stasenko <[hidden email]>:

> On 24 February 2010 09:25, Stéphane Ducasse <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Stéphane Ducasse
thanks for the answer.
Now since this is not top priority for me, if somebody check and produce a slice for pharo it will happen
else it will be postponed.

Note that for me the API of the compiler sucks and I would prefer to use cycle for fixing it.


Stef

On Feb 24, 2010, at 9:09 AM, Nicolas Cellier wrote:

> 2010/2/24 Igor Stasenko <[hidden email]>:
>> On 24 February 2010 09:25, Stéphane Ducasse <[hidden email]> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Nicolas Cellier
In reply to this post by Nicolas Cellier
2010/2/24 Nicolas Cellier <[hidden email]>:

> 2010/2/24 Igor Stasenko <[hidden email]>:
>> On 24 February 2010 09:25, Stéphane Ducasse <[hidden email]> 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
>

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

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Nicolas Cellier
In reply to this post by Lukas Renggli
2010/2/24 Lukas Renggli <[hidden email]>:

>> 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..
>
> I checked in the ANSI standard. Igor is right:
>
> == ANSI: 3.5.6 Numbers ======
>
>  binaryCharacter ::= '!' | '%' | '&'' | '*' | '+' | ','' | '/' | '<'
> | '=' | '>' | '?' | '@' | '\' | '~' | '|' | '-'
>  binarySelector ::= binaryCharacter+
>
> Binary selectors are method selectors that appear similar to
> mathematical operators. A binary selector may be any length greater
> than or equal to one. If a negative <number literal> follows a binary
> selector there must intervening white space."
>
> =========================
>
> I somehow remembered the grammar differently and that the $- was only
> allowed in the first position. This doesn't seem to be the case though
> (any longer) :-/
>
> I am not against changing the grammar to conform to ANSI and VW. I
> think that would actually be a good move, even if it is probably not
> really relevant in practice. I am however strongly against asking the
> user to disambiguate an expression. The compiler should compile what
> the user types, not guess what else he could have ment to say.
>
> Lukas
>

Then the question is how you compile 1@-2 and how you provide backward
compatibility.

Nicolas

> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Igor Stasenko
On 24 February 2010 10:15, Nicolas Cellier
<[hidden email]> wrote:

> 2010/2/24 Lukas Renggli <[hidden email]>:
>>> 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..
>>
>> I checked in the ANSI standard. Igor is right:
>>
>> == ANSI: 3.5.6 Numbers ======
>>
>>  binaryCharacter ::= '!' | '%' | '&'' | '*' | '+' | ','' | '/' | '<'
>> | '=' | '>' | '?' | '@' | '\' | '~' | '|' | '-'
>>  binarySelector ::= binaryCharacter+
>>
>> Binary selectors are method selectors that appear similar to
>> mathematical operators. A binary selector may be any length greater
>> than or equal to one. If a negative <number literal> follows a binary
>> selector there must intervening white space."
>>
>> =========================
>>
>> I somehow remembered the grammar differently and that the $- was only
>> allowed in the first position. This doesn't seem to be the case though
>> (any longer) :-/
>>
>> I am not against changing the grammar to conform to ANSI and VW. I
>> think that would actually be a good move, even if it is probably not
>> really relevant in practice. I am however strongly against asking the
>> user to disambiguate an expression. The compiler should compile what
>> the user types, not guess what else he could have ment to say.
>>
>> Lukas
>>
>
> Then the question is how you compile 1@-2 and how you provide backward
> compatibility.
>

As i said, i was always assumed that our parser works as ANSI says..
So, personally, i don't care about those who not followed it :)
But yes, compatibility is now an issue :(

Darn, why introducing a non-uniformity in syntax in a such way?
When i hearing "hey, smalltalk expressions don't follow the 'usual'
operators order of priority", i was always said - we don't need a
non-uniform rules which complicating the syntax! But now , what a
shame.. we actually having those! :)

> Nicolas
>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Lukas Renggli
In reply to this post by Nicolas Cellier
> Then the question is how you compile 1@-2 and how you provide backward
> compatibility.

You don't, because this is easy to fix, the ANSI standard is very
clear, and it does not prevent code from being loaded.

The situation occurs mostly in very old code:

  Cursor class>>initBottomRight
  Cursor class>>initResizeLeft
  Cursor class>>initNormalWithMask
  Cursor class>>initResizeTopLeft
  Cursor class>>initCorner
  Cursor class>>initCrossHair
  Cursor class>>initSquare
  Cursor class>>initResizeTop
  Cursor class>>initResizeTopRight
  Cursor class>>initBottomLeft
  DisplayHostWindow>>test2
  FlapTab>>fitContents
  FontChooserMorph>>createWindow
  Form>>findShapeAroundSeedBlock:
  Form>>pageImage:at:corner:
  Form class>>xorHack:
  Form class>>toothpaste:
  FuzzyLabelMorph>>drawOn:
  GroupboxMorph>>newLabelMorph
  GroupboxMorph>>initialize
  MethodFinder>>testRandom
  MethodFinder>>testFromTuple:
  Morph>>changeColorTarget:selector:originalColor:hand:
  PaintBoxMorph>>init4
  PaintBoxMorph>>fixUpColorPicker
  Point>>fourNeighbors
  Point>>eightNeighbors
  PolygonMorph>>nudgeForLabel:
  PreDebugWindow>>adjustBookControls
  SVColorSelectorMorph>>mouseEnterDragging:
  SVColorSelectorMorph>>mouseDown:
  SystemWindow>>minimizeOrRestore
  SystemWindow>>minimizeAfterGeneratingThumbnail
  TTSampleFontMorph>>drawCharactersOn:
  TTSampleStringMorph>>computeTransform
  TabGroupMorph>>initialize
  UIThemeW2K>>tabSelectorMorphMinExtentFor:

I did not find a single occurrence in Seaside, Magritte, Pier,
OmniBrowser, RB, NewCompiler, XML, PetitParser, GraphViz, and dozens
of other packages from SqueakSource that I have in my image.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Stéphane Ducasse
In reply to this post by Nicolas Cellier
Do you have an estimate of the code that you would break?

Stef

On Feb 24, 2010, at 9:14 AM, Nicolas Cellier wrote:

> 2010/2/24 Nicolas Cellier <[hidden email]>:
>> 2010/2/24 Igor Stasenko <[hidden email]>:
>>> On 24 February 2010 09:25, Stéphane Ducasse <[hidden email]> 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
>>
>
> 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
>
>>>
>>>>>
>>>>
>>>> Stef
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Stéphane Ducasse
In reply to this post by Nicolas Cellier
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Lukas Renggli
In reply to this post by Stéphane Ducasse
> Do you have an estimate of the code that you would break?

It breaks the methods given above.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)

Stéphane Ducasse
Ok so we could fix that easily I imagine

Stef

On Feb 24, 2010, at 12:59 PM, Lukas Renggli wrote:

>> Do you have an estimate of the code that you would break?
>
> It breaks the methods given above.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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