[squeak-dev] Re: [bug] xor: is this an old bug or what?

Klaus D. Witzel klaus.witzel at cobss.com
Thu Mar 26 18:53:44 UTC 2009


On Thu, 26 Mar 2009 17:21:08 +0100, Eliot Miranda wrote:

> On Tue, Mar 24, 2009 at 9:27 PM, Klaus D. Witzel wrote:
>
>> On Tue, 24 Mar 2009 23:01:45 +0100, Eliot Miranda wrote:
>>
>>  On Tue, Mar 24, 2009 at 1:36 PM, Randal L. Schwartz wrote:
>>>
>>>  >>>>> "Eliot" == Eliot Miranda <eliot.miranda at gmail.com> writes:
>>>>
>>>> Eliot> I think just
>>>>
>>>> True> xor: aBoolean
>>>> Eliot>     ^aBoolean not
>>>>
>>>> False> xor: aBoolean
>>>> Eliot>     ^aBoolean
>>>>
>>>> Eliot> and then leave subsequent usage to catch possible type errors;
>>>> e.g.
>>>> (false
>>>> Eliot> xor: #blah) ifTrue: ... will raise a mustBeBoolean error.
>>>>
>>>> What I don't like about this is that the right operand doesn't get a
>>>> chance
>>>> to
>>>> "boolify" itself, or define its own xor logic.  The double-dispatch
>>>> versions
>>>> were a lot better at that.
>>>>
>>>>  If you want to do that you could implement it as
>>>
>>> False> xor: aBoolean
>>>    ^aBoolean not not
>>>
>>
>> This is, by Randal E. Bryant (who's using Shannon's expansion),  
>> equivalent
>> to
>>
>>  ^ aBoolean ifTrue: [true] ifFalse: [false]
>>
>> which the Squeak inlining compiler's magic + decompiler transforms to
>>
>>  ^ aBoolean and: [true]
>>
>> When implemented in one of these two forms, a comment can explain that  
>> it's
>> a not not implementation.
>>
>>  but I'd argue that isn't necessary. The old code didn't type check and
>>> we've lived with it for a loooong time.
>>>
>>
>> I think that Randal makes the point; especially when the result is  
>> stored
>> for later.
>
>
> While it might be convenient it isn't strictly necessary.

Right. I was coming from here: given z the result and p,q operands for  
#xor:, then

  z := p xor: q
=>
  z := p ifTrue: [q not] ifFalse: [q]
=>
  that is, q must be evaluated in both cases. This is how I would inline  
#xor:, by sending the single #not conditionally.

> Smalltalk defers
> type checks until usage.  Not checking in False>>xor: would be consistent
> with this.

Sure. If people do like conditional evaluation of #xor:'s argument then  
let 'em have it :)

> The other boolean messages do implicit (by the inlining compiler) check
>> their argument for #isBoolean, that's what should be done by #xor: as  
>> well.
>
>
> No they do not.  Look at | and & :
>
> False>>| aBoolean
> "Evaluating disjunction (OR) -- answer with the argument, aBoolean."
>
> ^aBoolean
>
> True>>&& alternativeObject
> "Evaluating conjunction -- answer alternativeObject since receiver is  
> true."
>
> ^alternativeObject
>
>
> But in any case, the not is a form of double-dispatch.  It just points  
> out
> that one can use not instead of xorTrue and is more comprehensible  
> because "not" is familiar.

NP.

>>>
>>>
>>>> --
>>>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
>>>> 0095
>>>> <merlyn at 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
>>>>
>>>
>> --
>> "If at first, the idea is not absurd, then there is no hope for it".  
>> Albert
>> Einstein
>>




More information about the Squeak-dev mailing list