#and:and:and: deprecated on 1.1, why?
Locked
12
12
Re: #and:and:and: deprecated on 1.1, why?
 
|
>> - The exact semantics of #and:and:and: is not clear without knowing
>> how it is implemented. >> >> - There are subtle semantic differences between "a and: [ b ] and: [ c >> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >> conditions have side-effects. > > That's not true. Both #and: and #and:and:and: (and friends) are > short-circuit, so they'll cause exactly the same side effects. I know that and this is *not* what I am talking about. What you point out is already discussed above, it is absolutely unclear what #and:and:and: does without looking at the implementation. The point is that blocks that are lexically nested "a and: [ b and: [ c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ c ]" do not have the same expressive power (temps, state) and do not necessarily behave the same. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Stéphane Ducasse
On 26 May 2010 15:16, Stéphane Ducasse <[hidden email]> wrote:
> In general (but it often does not work :)) having a lot of conditions in OOP > means that you are missing class to dispatch on then. > Yup. Another argument to kill and:and:and: It reminds me isKindOf:orOf: >> But then which is the equivalence to #and:and:and: when I have many >> conditions? > > a and: [b] and: [c] > > if a and c do not have side effect that may change the condition are equivalent > to > a and: [ b and: [c]] > > so you have express what you want > >> Perhaps I will say a stupidity... but , not is valid the implementation of >> #&& and #|| messages instead of #and:... #or: .....? > > > & and | are executing all their arguments while > true & error -> error > true and: [error] -> true but it is more costly > > >> >> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >> >> >> Regards >> -- >> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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: #and:and:and: deprecated on 1.1, why?
|
|
> Yup. Another argument to kill and:and:and:
> It reminds me > isKindOf:orOf: Ah ah ah! #isKindOf:orOf: Woooaaaa.... Your email made me laugh. Thanks Igor :-) Cheers, Alexandre > >>> But then which is the equivalence to #and:and:and: when I have many >>> conditions? >> >> a and: [b] and: [c] >> >> if a and c do not have side effect that may change the condition are equivalent >> to >> a and: [ b and: [c]] >> >> so you have express what you want >> >>> Perhaps I will say a stupidity... but , not is valid the implementation of >>> #&& and #|| messages instead of #and:... #or: .....? >> >> >> & and | are executing all their arguments while >> true & error -> error >> true and: [error] -> true but it is more costly >> >> >>> >>> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >>> >>> >>> Regards >>> -- >>> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Igor Stasenko
Lukas already answered very well.
From core designer point of view, the questions is what additionnal value is brought by #and:and:and: ? - does it add expressiveness against nested and: [and: [ and: [ ] ] ] ? Not much - does it shorten code ? No - does it enable some optimization ? No If it has no value, then we should better remove it and simplify the API. Nicolas 2010/5/26 Igor Stasenko <[hidden email]>: > On 26 May 2010 15:16, Stéphane Ducasse <[hidden email]> wrote: >> In general (but it often does not work :)) having a lot of conditions in OOP >> means that you are missing class to dispatch on then. >> > Yup. Another argument to kill and:and:and: > It reminds me > isKindOf:orOf: > >>> But then which is the equivalence to #and:and:and: when I have many >>> conditions? >> >> a and: [b] and: [c] >> >> if a and c do not have side effect that may change the condition are equivalent >> to >> a and: [ b and: [c]] >> >> so you have express what you want >> >>> Perhaps I will say a stupidity... but , not is valid the implementation of >>> #&& and #|| messages instead of #and:... #or: .....? >> >> >> & and | are executing all their arguments while >> true & error -> error >> true and: [error] -> true but it is more costly >> >> >>> >>> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >>> >>> >>> Regards >>> -- >>> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
Another point that I feel is important for banning and:and:... is that it makes code harder to refactor.
Consider: #1: exp1 and: [exp2] and: [exp3] and #2: (exp1 and: [exp2]) and: [exp3] In #2, I can select what is inside (...) and press extract to method. In #1, I cannot select "exp1 and: [exp2]" and extract. The rb engine will not like it. And I would not expect the rb engine to extract piece of a message call into a new method. Cheers, Alexandre On 26 May 2010, at 12:16, Nicolas Cellier wrote: > Lukas already answered very well. > From core designer point of view, the questions is what additionnal > value is brought by #and:and:and: ? > - does it add expressiveness against nested and: [and: [ and: [ ] ] ] ? Not much > - does it shorten code ? No > - does it enable some optimization ? No > If it has no value, then we should better remove it and simplify the API. > > Nicolas > > 2010/5/26 Igor Stasenko <[hidden email]>: >> On 26 May 2010 15:16, Stéphane Ducasse <[hidden email]> wrote: >>> In general (but it often does not work :)) having a lot of conditions in OOP >>> means that you are missing class to dispatch on then. >>> >> Yup. Another argument to kill and:and:and: >> It reminds me >> isKindOf:orOf: >> >>>> But then which is the equivalence to #and:and:and: when I have many >>>> conditions? >>> >>> a and: [b] and: [c] >>> >>> if a and c do not have side effect that may change the condition are equivalent >>> to >>> a and: [ b and: [c]] >>> >>> so you have express what you want >>> >>>> Perhaps I will say a stupidity... but , not is valid the implementation of >>>> #&& and #|| messages instead of #and:... #or: .....? >>> >>> >>> & and | are executing all their arguments while >>> true & error -> error >>> true and: [error] -> true but it is more costly >>> >>> >>>> >>>> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >>>> >>>> >>>> Regards >>>> -- >>>> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > 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: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Peter Hugosson-Miller
2010/5/26 Peter Hugosson-Miller <[hidden email]> Thanks, Lucas! The fundamental ones are that value[:value:]* a) avoid consing up the array to hold the arguments and b) avoid determining the array's size and dereferencing it when evaluating. The value[:value:]* primitives are as a result usefully more streamlined than the valueWithArguments: primitive. That may still be a historical argument but I still find it compelling:
| b n | b := [:aa :ab| ]. n := 10000000. { Time millisecondsToRun: [1 to: n do: [:i| b value: 0 value: 0]]. Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: {0. 0}]].
Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: #(0 0)]] } Squeak 4.1.1beta2: #(1357 2129 1457) Cog: #(141 844 568) (2.66 GHz Intel Core i7)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Igor Stasenko
>> In general (but it often does not work :)) having a lot of conditions in OOP
>> means that you are missing class to dispatch on then. >> > Yup. Another argument to kill and:and:and: > It reminds me > isKindOf:orOf: lol next one on my radar would be findA: or friends in morph findAThat: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Eliot Miranda-2
any idea why on pharo 1.1
| b n | b := [:aa :ab| ]. n := 10000000. { Time millisecondsToRun: [1 to: n do: [:i| b value: 0 value: 0]]. Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: {0. 0}]]. Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: #(0 0)]] } #(1597 2606 1696) On May 26, 2010, at 6:49 PM, Eliot Miranda wrote: > | b n | > b := [:aa :ab| ]. > n := 10000000. > { Time millisecondsToRun: [1 to: n do: [:i| b value: 0 value: 0]]. > Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: {0. 0}]]. > Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: #(0 0)]] } _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
Stéphane Ducasse wrote:
> any idea why on pharo 1.1 > > | b n | > b := [:aa :ab| ]. > n := 10000000. > { Time millisecondsToRun: [1 to: n do: [:i| b value: 0 value: 0]]. > Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: {0. 0}]]. > Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: #(0 0)]] } > > #(1597 2606 1696) Presumably the Array constructor {...} is more costly than a literal Array, which makese sense. Dale _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Lukas Renggli
On Wed, 26 May 2010, Lukas Renggli wrote:
>>> - The exact semantics of #and:and:and: is not clear without knowing >>> how it is implemented. >>> >>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>> conditions have side-effects. >> >> That's not true. Both #and: and #and:and:and: (and friends) are >> short-circuit, so they'll cause exactly the same side effects. > > I know that and this is *not* what I am talking about. What you point > out is already discussed above, it is absolutely unclear what > #and:and:and: does without looking at the implementation. > > The point is that blocks that are lexically nested "a and: [ b and: [ > c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ > c ]" do not have the same expressive power (temps, state) and do not > necessarily behave the same. Maybe i'm just narrow-minded, but I can't see the difference except for the scope of temporaries defined inside blocks. Levente > > Lukas > > -- > Lukas Renggli > 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: #and:and:and: deprecated on 1.1, why?
|
|
On 26 May 2010 20:47, Levente Uzonyi <[hidden email]> wrote:
> On Wed, 26 May 2010, Lukas Renggli wrote: > >>>> - The exact semantics of #and:and:and: is not clear without knowing >>>> how it is implemented. >>>> >>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>> conditions have side-effects. >>> >>> That's not true. Both #and: and #and:and:and: (and friends) are >>> short-circuit, so they'll cause exactly the same side effects. >> >> I know that and this is *not* what I am talking about. What you point >> out is already discussed above, it is absolutely unclear what >> #and:and:and: does without looking at the implementation. >> >> The point is that blocks that are lexically nested "a and: [ b and: [ >> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >> c ]" do not have the same expressive power (temps, state) and do not >> necessarily behave the same. > > Maybe i'm just narrow-minded, but I can't see the difference except for the > scope of temporaries defined inside blocks. > For pushing a closure on stack, an interpreter makes a copy of closure literal, from method's literal frame. For expressions like: a and: [ b ] and: [ c ] it should prepare and push 2 closures. and for expression like: a and: [ b and: [ c ] ] just one. So it is faster, for cases when outer block is not activated, because a is false. > > Levente > >> >> Lukas >> >> -- >> Lukas Renggli >> 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: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Dale Henrichs
but I was comparing with squeak :)
I'm on 2.53 intel core 2 duo so may be the difference is that. Squeak 4.1.1beta2: #(1357 2129 1457) Cog: #(141 844 568) (2.66 GHz Intel Core i7) On May 26, 2010, at 7:30 PM, Dale Henrichs wrote: > Stéphane Ducasse wrote: >> any idea why on pharo 1.1 >> | b n | >> b := [:aa :ab| ]. >> n := 10000000. >> { Time millisecondsToRun: [1 to: n do: [:i| b value: 0 value: 0]]. >> Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: {0. 0}]]. >> Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: #(0 0)]] } #(1597 2606 1696) > > Presumably the Array constructor {...} is more costly than a literal Array, which makese sense. > > Dale > > _______________________________________________ > 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: #and:and:and: deprecated on 1.1, why?
|
|
On Wed, May 26, 2010 at 11:41 AM, Stéphane Ducasse <[hidden email]> wrote: but I was comparing with squeak :) Indeed that's one difference. Only the ratios matter. Different machines have different performance at different times of the day. e.g. run another performance-intensive program while you're collecting results and you've just collected some useless results.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Igor Stasenko
On Wed, 26 May 2010, Igor Stasenko wrote:
> On 26 May 2010 20:47, Levente Uzonyi <[hidden email]> wrote: >> On Wed, 26 May 2010, Lukas Renggli wrote: >> >>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>> how it is implemented. >>>>> >>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>> conditions have side-effects. >>>> >>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>> short-circuit, so they'll cause exactly the same side effects. >>> >>> I know that and this is *not* what I am talking about. What you point >>> out is already discussed above, it is absolutely unclear what >>> #and:and:and: does without looking at the implementation. >>> >>> The point is that blocks that are lexically nested "a and: [ b and: [ >>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>> c ]" do not have the same expressive power (temps, state) and do not >>> necessarily behave the same. >> >> Maybe i'm just narrow-minded, but I can't see the difference except for the >> scope of temporaries defined inside blocks. >> > > For pushing a closure on stack, an interpreter makes a copy of closure > literal, from method's literal frame. > For expressions like: > a and: [ b ] and: [ c ] > > it should prepare and push 2 closures. > > and for expression like: > > a and: [ b and: [ c ] ] > > just one. > So it is faster, for cases when outer block is not activated, because > a is false. I understand this. And I know that the current compiler will inline the blocks in the second case which gives the real difference in speed. What I don't understand is: how can these two expressions behave differently. Can you provide a, b and c which will behave differently if evaluated as: 1) a and: [ b ] and: [ c ] and 2) a and: [ b and: [ c ] ] ? Levente > >> >> Levente >> >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> 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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
On 26 May 2010 22:18, Levente Uzonyi <[hidden email]> wrote:
> On Wed, 26 May 2010, Igor Stasenko wrote: > >> On 26 May 2010 20:47, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Wed, 26 May 2010, Lukas Renggli wrote: >>> >>>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>> how it is implemented. >>>>>> >>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>> conditions have side-effects. >>>>> >>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>> short-circuit, so they'll cause exactly the same side effects. >>>> >>>> I know that and this is *not* what I am talking about. What you point >>>> out is already discussed above, it is absolutely unclear what >>>> #and:and:and: does without looking at the implementation. >>>> >>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>> c ]" do not have the same expressive power (temps, state) and do not >>>> necessarily behave the same. >>> >>> Maybe i'm just narrow-minded, but I can't see the difference except for >>> the >>> scope of temporaries defined inside blocks. >>> >> >> For pushing a closure on stack, an interpreter makes a copy of closure >> literal, from method's literal frame. >> For expressions like: >> a and: [ b ] and: [ c ] >> >> it should prepare and push 2 closures. >> >> and for expression like: >> >> a and: [ b and: [ c ] ] >> >> just one. >> So it is faster, for cases when outer block is not activated, because >> a is false. > > I understand this. And I know that the current compiler will inline the > blocks in the second case which gives the real difference in speed. > > What I don't understand is: how can these two expressions behave > differently. Can you provide a, b and c which will behave differently if > evaluated as: > 1) a and: [ b ] and: [ c ] > and > 2) a and: [ b and: [ c ] ] > ? > And there's no way how #and:and: could provide similar behavior. > > Levente > >> >>> >>> Levente >>> >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> 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 >> > > _______________________________________________ > 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: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Levente Uzonyi-2
They do not behave different. The problem is that you cannot assume that by just looking at the message send.
They could behave different, they do not, but you don't know that until you look at the method implementation. You cannot assume that #and:and:and: will or wont evaluate the second block and then compare the results. In fact, it's almost suggested in the declaration that it will by hierarchically organizing the blocks in the same logical level. And that is a lack of expressiveness. For that, is preferred the second option. Besides, #and:and:and: implementation is horrible :) Cheers, Mariano. On Wed, May 26, 2010 at 4:18 PM, Levente Uzonyi <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Henrik Sperre Johansen
Em 26/05/2010 07:07, Henrik Johansen < [hidden email] > escreveu:
> On May 26, 2010, at 11:58 51AM, Stéphane Ducasse wrote: > > > hi richard > > > >> WTF?! > > If you have a real argument we are really open to discussion. > > > >> These are the only reasons? I think that they are sufficient > +1 > > Because we could have and:or: or:and: and:and:or: and a couple of > others in that case. > No we could not :) Because of ambiguity: a and: (b or: c) is not > the same as (a and: b) or: c I disagree. Since to implement this in Smalltalk you'll need a specific method the ambiguity can be removed by specifying the API and using the appropriate implementation: Boolean>> and: x or: y ^(self and: x) or: y _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: #and:and:and: deprecated on 1.1, why?
|
|
In reply to this post by Igor Stasenko
On Wed, 26 May 2010, Igor Stasenko wrote:
> On 26 May 2010 22:18, Levente Uzonyi <[hidden email]> wrote: >> On Wed, 26 May 2010, Igor Stasenko wrote: >> >>> On 26 May 2010 20:47, Levente Uzonyi <[hidden email]> wrote: >>>> >>>> On Wed, 26 May 2010, Lukas Renggli wrote: >>>> >>>>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>>> how it is implemented. >>>>>>> >>>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>>> conditions have side-effects. >>>>>> >>>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>>> short-circuit, so they'll cause exactly the same side effects. >>>>> >>>>> I know that and this is *not* what I am talking about. What you point >>>>> out is already discussed above, it is absolutely unclear what >>>>> #and:and:and: does without looking at the implementation. >>>>> >>>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>>> c ]" do not have the same expressive power (temps, state) and do not >>>>> necessarily behave the same. >>>> >>>> Maybe i'm just narrow-minded, but I can't see the difference except for >>>> the >>>> scope of temporaries defined inside blocks. >>>> >>> >>> For pushing a closure on stack, an interpreter makes a copy of closure >>> literal, from method's literal frame. >>> For expressions like: >>> a and: [ b ] and: [ c ] >>> >>> it should prepare and push 2 closures. >>> >>> and for expression like: >>> >>> a and: [ b and: [ c ] ] >>> >>> just one. >>> So it is faster, for cases when outer block is not activated, because >>> a is false. >> >> I understand this. And I know that the current compiler will inline the >> blocks in the second case which gives the real difference in speed. >> >> What I don't understand is: how can these two expressions behave >> differently. Can you provide a, b and c which will behave differently if >> evaluated as: >> 1) a and: [ b ] and: [ c ] >> and >> 2) a and: [ b and: [ c ] ] >> ? >> > Trivial. I could implement own #and: method in my class. > And there's no way how #and:and: could provide similar behavior. Nice idea, but there's no a, b or c in it (which evaluate to a Boolean). Anyway if you implement a method named #and:, you won't be able to use it, since #and: is inlined. (Which means that it's like a keyword, you can't reuse it without changing the compiler. This is another reason why inlining more methods is a bad idea.) Levente > > >> >> Levente >> >>> >>>> >>>> Levente >>>> >>>>> >>>>> Lukas >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> 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 >>> >> >> _______________________________________________ >> 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: #and:and:and: deprecated on 1.1, why?
|
|
On 27 May 2010 01:57, Levente Uzonyi <[hidden email]> wrote:
> On Wed, 26 May 2010, Igor Stasenko wrote: > >> On 26 May 2010 22:18, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Wed, 26 May 2010, Igor Stasenko wrote: >>> >>>> On 26 May 2010 20:47, Levente Uzonyi <[hidden email]> wrote: >>>>> >>>>> On Wed, 26 May 2010, Lukas Renggli wrote: >>>>> >>>>>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>>>> how it is implemented. >>>>>>>> >>>>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ >>>>>>>> c >>>>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>>>> conditions have side-effects. >>>>>>> >>>>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>>>> short-circuit, so they'll cause exactly the same side effects. >>>>>> >>>>>> I know that and this is *not* what I am talking about. What you point >>>>>> out is already discussed above, it is absolutely unclear what >>>>>> #and:and:and: does without looking at the implementation. >>>>>> >>>>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>>>> c ]" do not have the same expressive power (temps, state) and do not >>>>>> necessarily behave the same. >>>>> >>>>> Maybe i'm just narrow-minded, but I can't see the difference except for >>>>> the >>>>> scope of temporaries defined inside blocks. >>>>> >>>> >>>> For pushing a closure on stack, an interpreter makes a copy of closure >>>> literal, from method's literal frame. >>>> For expressions like: >>>> a and: [ b ] and: [ c ] >>>> >>>> it should prepare and push 2 closures. >>>> >>>> and for expression like: >>>> >>>> a and: [ b and: [ c ] ] >>>> >>>> just one. >>>> So it is faster, for cases when outer block is not activated, because >>>> a is false. >>> >>> I understand this. And I know that the current compiler will inline the >>> blocks in the second case which gives the real difference in speed. >>> >>> What I don't understand is: how can these two expressions behave >>> differently. Can you provide a, b and c which will behave differently if >>> evaluated as: >>> 1) a and: [ b ] and: [ c ] >>> and >>> 2) a and: [ b and: [ c ] ] >>> ? >>> >> Trivial. I could implement own #and: method in my class. >> And there's no way how #and:and: could provide similar behavior. > > Nice idea, but there's no a, b or c in it (which evaluate to a Boolean). > Anyway if you implement a method named #and:, you won't be able to use it, > since #and: is inlined. (Which means that it's like a keyword, you can't > reuse it without changing the compiler. This is another reason why inlining > more methods is a bad idea.) > not get caught. Isnt? :) In smalltalk, i can send #and: message to any object. And from this point , there is no way how #and:and: could provide similar behavior, unless my class also implements it. > > Levente > >> >> >>> >>> Levente >>> >>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ 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 |