[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
|