[Pharo-project] About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
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
On 24 February 2010 09:25, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
2010/2/24 Lukas Renggli <renggli@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24 February 2010 10:15, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/2/24 Lukas Renggli <renggli@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
2010/2/24 Igor Stasenko <siguctua@gmail.com>:
On 24 February 2010 09:25, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <siguctua@gmail.com>:
On 24 February 2010 09:25, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/2/24 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2010/2/24 Igor Stasenko <siguctua@gmail.com>:
On 24 February 2010 09:25, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <nicolas.cellier.aka.nice@gmail.com>:
2010/2/24 Igor Stasenko <siguctua@gmail.com>:
On 24 February 2010 09:25, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
participants (4)
-
Igor Stasenko -
Lukas Renggli -
Nicolas Cellier -
Stéphane Ducasse