Having fun with booleans
Locked
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Having fun with booleans
|
|
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 <[hidden email]> 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 > [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: [squeak-dev] Having fun with booleans
|
|
In reply to this post by Igor Stasenko
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Peter Hugosson-Miller
On 5 March 2010 09:26, Peter Hugosson-Miller <[hidden email]> 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 <[hidden email]> 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 >> [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: [squeak-dev] Having fun with booleans
|
|
In reply to this post by Lukas Renggli
>>>>> "Lukas" == Lukas Renggli <[hidden email]> 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 <[hidden email]> <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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Having fun with booleans
|
|
In reply to this post by Igor Stasenko
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 > [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: Having fun with booleans
|
|
On 5 mar 2010, at 09.33, Fernando olivero <[hidden email]> 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 >> [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: Having fun with booleans
|
|
Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: > On 5 mar 2010, at 09.33, Fernando olivero <[hidden email]> 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 > 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 >>> [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 > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Having fun with booleans
|
|
On 5 mar 2010, at 10.17, Henrik Johansen
<[hidden email]> wrote: > > > Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: >> On 5 mar 2010, at 09.33, Fernando olivero <[hidden email]> >> 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 >>>> [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 >> >> >> > > _______________________________________________ > 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 |
|
|
In reply to this post by Henrik Sperre Johansen
On 5 March 2010 11:17, Henrik Johansen <[hidden email]> wrote:
> > > Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: >> On 5 mar 2010, at 09.33, Fernando olivero <[hidden email]> 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 >>>> [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 >> >> >> > > _______________________________________________ > 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 |
|
|
In reply to this post by Igor Stasenko
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 < [hidden email] > 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 [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 |