About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
Locked
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
> 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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
Re: About changes and so on: Authorize - at any position in binary selectors (like VW 7.7)
|
|
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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |