[Pharo-project] Having fun with booleans
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead. a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ] a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ] and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as: a > b and: [ self foo]; or:[ self bar ] :) -- Best regards, Igor Stasenko AKA sig.
Hehe, it wouldn't surprise me if some of those examples would compile to the same byte codes. Have you tried decompiling to see what you get? -- Cheers, Peter. On 5 mar 2010, at 08.22, Igor Stasenko <siguctua@gmail.com> wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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
On 5 March 2010 09:26, Peter Hugosson-Miller <oldmanlink@gmail.com> wrote:
Hehe, it wouldn't surprise me if some of those examples would compile to the same byte codes. Have you tried decompiling to see what you get?
Not that i'm really interested in using it in such fashion :) It just an observation.
-- Cheers, Peter.
On 5 mar 2010, at 08.22, Igor Stasenko <siguctua@gmail.com> wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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.
I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
[...]
This reminds me of cryptic expressions like command && success || failure in other languages. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
"Lukas" == Lukas Renggli <renggli@gmail.com> writes:
Lukas> This reminds me of cryptic expressions like Lukas> command && success || failure Lukas> in other languages. Which breaks if success doesn't also return true, which is why I *yell loudly* and *angrily* when anyone uses that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
The problem is the side effects, is suddenly Boolean>>and: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated. Fernando On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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
On 5 mar 2010, at 09.33, Fernando olivero <oliverof@lu.unisi.ch> wrote:
The problem is the side effects, is suddenly Boolean>>and: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated.
No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure. But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading. -- Cheers, Peter
Fernando
On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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
Den 05.03.2010 10:08, skrev Peter Hugosson-Miller:
On 5 mar 2010, at 09.33, Fernando olivero <oliverof@lu.unisi.ch> wrote:
The problem is the side effects, is suddenly Boolean>>and: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated.
No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure.
But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading.
-- Cheers, Peter
I like that argument turned on its head, namely that ifTrue: ifFalse: gives the reader a very strong hint that the argument blocks are used purely for branching, thus using them to (eventually) return a boolean can be seen as misleading :) i.e. I tend to prefer to use Igors and: example for code I often see written a < b ifTrue: [... a couple of actions, then returning true or false ...] ifFalse: [^false] Cheers, Henry
Fernando
On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 5 mar 2010, at 10.17, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
Den 05.03.2010 10:08, skrev Peter Hugosson-Miller:
On 5 mar 2010, at 09.33, Fernando olivero <oliverof@lu.unisi.ch> wrote:
The problem is the side effects, is suddenly Boolean>>and: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated.
No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure.
But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading.
-- Cheers, Peter
I like that argument turned on its head, namely that ifTrue: ifFalse: gives the reader a very strong hint that the argument blocks are used purely for branching, thus using them to (eventually) return a boolean can be seen as misleading :)
i.e. I tend to prefer to use Igors and: example for code I often see written
a < b ifTrue: [... a couple of actions, then returning true or false ...] ifFalse: [^false]
And I'm definitely with you on that score! In fact it's how I decide which method to use :-) -- Cheers, Peter
Cheers, Henry
Fernando
On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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
_______________________________________________ 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
On 5 March 2010 11:17, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
Den 05.03.2010 10:08, skrev Peter Hugosson-Miller:
On 5 mar 2010, at 09.33, Fernando olivero <oliverof@lu.unisi.ch> wrote:
The problem is the side effects, is suddenly Boolean>>and: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated.
No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure.
But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading.
-- Cheers, Peter
I like that argument turned on its head, namely that ifTrue: ifFalse: gives the reader a very strong hint that the argument blocks are used purely for branching, thus using them to (eventually) return a boolean can be seen as misleading :)
i.e. I tend to prefer to use Igors and: example for code I often see written
a < b ifTrue: [... a couple of actions, then returning true or false ...] Â Â Â Â ifFalse: [^false]
yes, sometimes i find it inconvenient ,that i can't do chaining: (a<b ifTrue: [ self foo. c<d ]) ifTrue: [ ... ] since #ifTrue: answers nil if condition evaluated to false.
Cheers, Henry
Fernando
On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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
_______________________________________________ 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.
Yes ;-) in fact Andrés Valloud wrote a book "Fundamentals of Smalltalk Programming Technique" which he discusses the theme of Booleans in Chapter 3 and specifically the optimization you discovered in 3.2.1. -- Cesar Rabak Em 05/03/2010 04:22, Igor Stasenko < siguctua@gmail.com > escreveu: Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead. a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ] a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ] and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as: a > b and: [ self foo]; or:[ self bar ] :) -- 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
participants (7)
-
csrabak＠bol.com.br -
Fernando olivero -
Henrik Johansen -
Igor Stasenko -
Lukas Renggli -
merlyn＠stonehenge.com -
Peter Hugosson-Miller