On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 22:18, Levente Uzonyi <leves@elte.hu> wrote:
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 20:47, Levente Uzonyi <leves@elte.hu> 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 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.
_______________________________________________ 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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project