Protocol extension proposal: Boolean>>asBit ?

>
> I currently writing a code which looks like:
>
> a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]).
>
> And i get somewhat tired repeating the same pattern in multiple places.
> So, i thinking , maybe #asBit convenience method could be useful?
>
> True>>asBit
>  ^ 1
> False>>asBit
>  ^ 0
>
> so, then, in case of need like above, we could write much shorter expressions:
> a := some numeric expression + someBoolean asBit.
>
> And its much less error prone comparing to #ifTrue:ifFalse:, since i
> found its relatively easy to make a mess (swapping 1 with 0),
> especially, when you having negations in expression, because once you see:
>
> (someBoolean not ifTrue: [1] ifFalse: [0])
>
> you always tempted to write it as:
>
> (someBoolean ifTrue: [0] ifFalse: [1]).
>
> or as:
>
> (someBoolean ifFalse: [1] ifTrue: [0]).
>
> but once you start playing with it, its very easy to shoot into own
> feet if you are not careful.
>
> But if we could add #asBit, then we could write:
>
> someBoolean not asBit
>
> which is much more:
> a) concise & cleaner
> b) error proof
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.

> On 05.12.2009, at 11:44, Igor Stasenko wrote:
>>
>> I currently writing a code which looks like:
>>
>> a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]).
>>
>> And i get somewhat tired repeating the same pattern in multiple places.
>> So, i thinking , maybe #asBit convenience method could be useful?
>>
>> True>>asBit
>>  ^ 1
>> False>>asBit
>>  ^ 0
>>
>> so, then, in case of need like above, we could write much shorter expressions:
>> a := some numeric expression + someBoolean asBit.
>>
>> And its much less error prone comparing to #ifTrue:ifFalse:, since i
>> found its relatively easy to make a mess (swapping 1 with 0),
>> especially, when you having negations in expression, because once you see:
>>
>> (someBoolean not ifTrue: [1] ifFalse: [0])
>>
>> you always tempted to write it as:
>>
>> (someBoolean ifTrue: [0] ifFalse: [1]).
>>
>> or as:
>>
>> (someBoolean ifFalse: [1] ifTrue: [0]).
>>
>> but once you start playing with it, its very easy to shoot into own
>> feet if you are not careful.
>>
>> But if we could add #asBit, then we could write:
>>
>> someBoolean not asBit
>>
>> which is much more:
>> a) concise & cleaner
>> b) error proof
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
> Wouldn't #asInteger be more appropriate?
>

>
> 2009/12/5 Bert Freudenberg <[hidden email]>:
>> On 05.12.2009, at 11:44, Igor Stasenko wrote:
>>>
>>> I currently writing a code which looks like:
>>>
>>> a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]).
>>>
>>> And i get somewhat tired repeating the same pattern in multiple places.
>>> So, i thinking , maybe #asBit convenience method could be useful?
>>>
>>> True>>asBit
>>>  ^ 1
>>> False>>asBit
>>>  ^ 0
>>>
>>> so, then, in case of need like above, we could write much shorter expressions:
>>> a := some numeric expression + someBoolean asBit.
>>>
>>> And its much less error prone comparing to #ifTrue:ifFalse:, since i
>>> found its relatively easy to make a mess (swapping 1 with 0),
>>> especially, when you having negations in expression, because once you see:
>>>
>>> (someBoolean not ifTrue: [1] ifFalse: [0])
>>>
>>> you always tempted to write it as:
>>>
>>> (someBoolean ifTrue: [0] ifFalse: [1]).
>>>
>>> or as:
>>>
>>> (someBoolean ifFalse: [1] ifTrue: [0]).
>>>
>>> but once you start playing with it, its very easy to shoot into own
>>> feet if you are not careful.
>>>
>>> But if we could add #asBit, then we could write:
>>>
>>> someBoolean not asBit
>>>
>>> which is much more:
>>> a) concise & cleaner
>>> b) error proof
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>
>> Wouldn't #asInteger be more appropriate?
>>
>
> Probably. But i choose a 'bit', because booleans is an enumeration
> type, not a number ,
> and its hard to expect that something which is not a number can be
> converted to number.
> Another reason why i cautious about #asInteger, that it is already
> exists & used widely and probably
> introducing it into boolean classes can be fatal to some applications.
>
> Maybe i'm overly cautious about that, if so, then #asInteger is just fine.

>
>>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
>
> Bert> I don't think it would break any sane application. #asInteger is
> Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect it to
> Bert> return an instance of Bit.
>
> Bert> I have not really felt the need for such a method, but I can see how
> Bert> it's tempting to have, in particular when porting code.
>
> It's also "according to who".  0 as false, 1 as true is only one encoding,
> and clearly not universal.  I've worked with systems where 0 is false,
> and -1 is true.

> True>>asBit
>  ^ 1
> False>>asBit
>  ^ 0
>
> so, then, in case of need like above, we could write much shorter expressions:
> a := some numeric expression + someBoolean asBit.
>
> And its much less error prone comparing to #ifTrue:ifFalse:, since i
> found its relatively easy to make a mess (swapping 1 with 0),
> especially, when you having negations in expression, because once you see:
>
> (someBoolean not ifTrue: [1] ifFalse: [0])
>
> you always tempted to write it as:
>
> (someBoolean ifTrue: [0] ifFalse: [1]).
>
> or as:
>
> (someBoolean ifFalse: [1] ifTrue: [0]).
>
> but once you start playing with it, its very easy to shoot into own
> feet if you are not careful.
>
> But if we could add #asBit, then we could write:
>
> someBoolean not asBit
>
> which is much more:
> a) concise & cleaner
> b) error proof
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
> >
> >>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
> >
> > Bert> I don't think it would break any sane application. #asInteger is
> > Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect it to
> > Bert> return an instance of Bit.
> >
> > Bert> I have not really felt the need for such a method, but I can see how
> > Bert> it's tempting to have, in particular when porting code.
> >
> > It's also "according to who".  0 as false, 1 as true is only one encoding,
> > and clearly not universal.  I've worked with systems where 0 is false,
> > and -1 is true.
>
> I knew someone would bring this up ;) I also like to KISS.
>
> This is not about internal representation, but about doing arithmetic with
> booleans. I don't think any other mapping than "true asInteger = 1" and
> "false asInteger = 0" makes sense in that context.

> On Sat, Dec 05, 2009 at 02:48:21PM +0100, Bert Freudenberg wrote:
>> On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
>> >
>> >>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
>> >
>> > Bert> I don't think it would break any sane application. #asInteger is
>> > Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect it to
>> > Bert> return an instance of Bit.
>> >
>> > Bert> I have not really felt the need for such a method, but I can see how
>> > Bert> it's tempting to have, in particular when porting code.
>> >
>> > It's also "according to who".  0 as false, 1 as true is only one encoding,
>> > and clearly not universal.  I've worked with systems where 0 is false,
>> > and -1 is true.
>>
>> I knew someone would bring this up ;) I also like to KISS.
>>
>> This is not about internal representation, but about doing arithmetic with
>> booleans. I don't think any other mapping than "true asInteger = 1" and
>> "false asInteger = 0" makes sense in that context.
>
> I don't think that arithmetic with booleans makes sense in any context.
>
> Is this convenience method really worth muddying up the distinction between
> numbers and booleans? Think of all the C programmers with bad habits
> (like me for example) who have had to stop and think twice about assuming
> that a number means the same thing as true or false.
>

>
> 2009/12/5 David T. Lewis <[hidden email]>:
>> On Sat, Dec 05, 2009 at 02:48:21PM +0100, Bert Freudenberg wrote:
>>> On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
>>>>
>>>>>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
>>>>
>>>> Bert> I don't think it would break any sane application. #asInteger is
>>>> Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect it to
>>>> Bert> return an instance of Bit.
>>>>
>>>> Bert> I have not really felt the need for such a method, but I can see how
>>>> Bert> it's tempting to have, in particular when porting code.
>>>>
>>>> It's also "according to who".  0 as false, 1 as true is only one encoding,
>>>> and clearly not universal.  I've worked with systems where 0 is false,
>>>> and -1 is true.
>>>
>>> I knew someone would bring this up ;) I also like to KISS.
>>>
>>> This is not about internal representation, but about doing arithmetic with
>>> booleans. I don't think any other mapping than "true asInteger = 1" and
>>> "false asInteger = 0" makes sense in that context.
>>
>> I don't think that arithmetic with booleans makes sense in any context.
>>
>> Is this convenience method really worth muddying up the distinction between
>> numbers and booleans? Think of all the C programmers with bad habits
>> (like me for example) who have had to stop and think twice about assuming
>> that a number means the same thing as true or false.
>>
>
> C is much closer to hardware than smalltalk. And we all know, that
> whatever you type of whatever program you will create in whatever
> language, the computers could represent it internally only as a
> sequence of bits.
>
> There are also couple things which can be seen as muddy. Consider #sign method:
>
> sign
> "Answer 1 if the receiver is greater than 0, -1 if less than 0, else 0."
>
> self > 0 ifTrue: [^1].
> self < 0 ifTrue: [^-1].
> ^0
>
> which could be also considered as a 'conversion' of boolean
> expressions to integer values, because i can implement it as:
>
> sign
>  ^ (self > 0) asBit - (self < 0) asBit.
>
> This is not the only place, where boolean values working together with
> numerical values.
> Consider rounding function(s):
>
> floor
> "Answer the integer nearest the receiver toward negative infinity."
>
> | truncation |
> truncation := self truncated.
> self >= 0 ifTrue: [^truncation].
> self = truncation
> ifTrue: [^truncation]
> ifFalse: [^truncation - 1]
>
> while we all get used to that rounding works *only* with numbers, it
> is impossible to implement them without using boolean algebra (but you
> may try, of course).
>
> Moreover, mathematicians using boolean expressions widely for defining
> a different weird-looking functions:
>
> f(x) =  {
>  (x<0) -x;
>  (x>=0) x;
> }
>
>
> So, i wouldn't say that we are first, who guilty by muddying booleans
> and numbers. It was happen a lot earlier and much more frequent in
> many areas.

> On 06.12.2009, at 00:36, Igor Stasenko wrote:
>>
>> 2009/12/5 David T. Lewis <[hidden email]>:
>>> On Sat, Dec 05, 2009 at 02:48:21PM +0100, Bert Freudenberg wrote:
>>>> On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
>>>>>
>>>>>>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
>>>>>
>>>>> Bert> I don't think it would break any sane application. #asInteger is
>>>>> Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect it to
>>>>> Bert> return an instance of Bit.
>>>>>
>>>>> Bert> I have not really felt the need for such a method, but I can see how
>>>>> Bert> it's tempting to have, in particular when porting code.
>>>>>
>>>>> It's also "according to who".  0 as false, 1 as true is only one encoding,
>>>>> and clearly not universal.  I've worked with systems where 0 is false,
>>>>> and -1 is true.
>>>>
>>>> I knew someone would bring this up ;) I also like to KISS.
>>>>
>>>> This is not about internal representation, but about doing arithmetic with
>>>> booleans. I don't think any other mapping than "true asInteger = 1" and
>>>> "false asInteger = 0" makes sense in that context.
>>>
>>> I don't think that arithmetic with booleans makes sense in any context.
>>>
>>> Is this convenience method really worth muddying up the distinction between
>>> numbers and booleans? Think of all the C programmers with bad habits
>>> (like me for example) who have had to stop and think twice about assuming
>>> that a number means the same thing as true or false.
>>>
>>
>> C is much closer to hardware than smalltalk. And we all know, that
>> whatever you type of whatever program you will create in whatever
>> language, the computers could represent it internally only as a
>> sequence of bits.
>>
>> There are also couple things which can be seen as muddy. Consider #sign method:
>>
>> sign
>>       "Answer 1 if the receiver is greater than 0, -1 if less than 0, else 0."
>>
>>       self > 0 ifTrue: [^1].
>>       self < 0 ifTrue: [^-1].
>>       ^0
>>
>> which could be also considered as a 'conversion' of boolean
>> expressions to integer values, because i can implement it as:
>>
>> sign
>>  ^ (self > 0) asBit - (self < 0) asBit.
>>
>> This is not the only place, where boolean values working together with
>> numerical values.
>> Consider rounding function(s):
>>
>> floor
>>       "Answer the integer nearest the receiver toward negative infinity."
>>
>>       | truncation |
>>       truncation := self truncated.
>>       self >= 0 ifTrue: [^truncation].
>>       self = truncation
>>               ifTrue: [^truncation]
>>               ifFalse: [^truncation - 1]
>>
>> while we all get used to that rounding works *only* with numbers, it
>> is impossible to implement them without using boolean algebra (but you
>> may try, of course).
>>
>> Moreover, mathematicians using boolean expressions widely for defining
>> a different weird-looking functions:
>>
>> f(x) =  {
>>  (x<0) -x;
>>  (x>=0) x;
>> }
>>
>>
>> So, i wouldn't say that we are first, who guilty by muddying booleans
>> and numbers. It was happen a lot earlier and much more frequent in
>> many areas.
>
> I hope you're not actually proposing to re-implement the above methods using #asBit (or #asInteger, for that matter) ...
>

> Hi,
>
>>yes, yes.  But real Smalltalk programs have to interface with external
>> programming languages, typically through a C-inlfuenced ABI.  In that
>> context it makes sense.  I second Bert's proposal,  true asInteger == 1
>> and: [false asInteger == 0].
>
> IMHO, we have started from one concrete & repetitive situation
>  and now the focus has gone to something completelly diferent, abstract,
>  in the field of "ideas/ideaLs"...
>
> Igor asked on how to solve the "problem" revealed by an expression like
>
>  value := aComputation + (aBoolean ifTrue: [ oneConstant ] ifFalse: [
> bConstant ])
>
> The "problem is solved" if we avoid instantiating the problem.
> Please consider WHY you have aBoolean there
>  and define/use a name for it;
>  I mean a name in correct scope (method, class, pool, etc) that is set
>  to the value(s) you need for computation and use that name instead
>  of "aBoolean".
> Check the place you instantiated aBoolean, imo, you will find that it
>  is in a place inside the same context (scope) of the expression. If it
>  is not the case, you should consider it in context of a tool (foreign,
>  more abstract) and provide at that level management for the naming
>  schema.
>

> Most times we can solve problems this way; rejecting the fact
>  that they occurs and that make our systems more independent
>  and scalable without suffering obesity.
>
> cheers,
> Ale.
>
>
>
>
>
>
> ----- Original Message -----
> From: Eliot Miranda
> To: The general-purpose Squeak developers list
> Sent: Saturday, December 05, 2009 6:09 PM
> Subject: Re: [squeak-dev] Protocol extension proposal: Boolean>>asBit ?
>
>
> On Sat, Dec 5, 2009 at 11:18 AM, David T. Lewis <[hidden email]> wrote:
>>
>> On Sat, Dec 05, 2009 at 02:48:21PM +0100, Bert Freudenberg wrote:
>> > On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
>> > >
>> > >>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
>> > >
>> > > Bert> I don't think it would break any sane application. #asInteger is
>> > > Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect
>> > > it to
>> > > Bert> return an instance of Bit.
>> > >
>> > > Bert> I have not really felt the need for such a method, but I can see
>> > > how
>> > > Bert> it's tempting to have, in particular when porting code.
>> > >
>> > > It's also "according to who".  0 as false, 1 as true is only one
>> > > encoding,
>> > > and clearly not universal.  I've worked with systems where 0 is false,
>> > > and -1 is true.
>> >
>> > I knew someone would bring this up ;) I also like to KISS.
>> >
>> > This is not about internal representation, but about doing arithmetic
>> > with
>> > booleans. I don't think any other mapping than "true asInteger = 1" and
>> > "false asInteger = 0" makes sense in that context.
>>
>> I don't think that arithmetic with booleans makes sense in any context.
>>
>> Is this convenience method really worth muddying up the distinction
>> between
>> numbers and booleans? Think of all the C programmers with bad habits
>> (like me for example) who have had to stop and think twice about assuming
>> that a number means the same thing as true or false.
>>
>> It seems to me that maintaining a clear distinction between numbers and
>> booleans is a Good Idea even if it does require some extra typing.
>
> yes, yes.  But real Smalltalk programs have to interface with external
> programming languages, typically through a C-inlfuenced ABI.  In that
> context it makes sense.  I second Bert's proposal,  true asInteger == 1 and:
> [false asInteger == 0].
>
>>
>> $0.02
>>
>> Dave
>>
>>
>
> ________________________________
>
>
>
>