On 26 May 2010 22:18, Levente Uzonyi <[email protected]> wrote: > On Wed, 26 May 2010, Igor Stasenko wrote: > >> On 26 May 2010 20:47, Levente Uzonyi <[email protected]> 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.
> > Levente > >> >>> >>> Levente >>> >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
