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

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 26 16:21:08 UTC 2009


On Tue, Mar 24, 2009 at 9:27 PM, Klaus D. Witzel <klaus.witzel at cobss.com>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.  Smalltalk defers
type checks until usage.  Not checking in False>>xor: would be consistent
with this.

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.
>>
>>
>>> --
>>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090326/af71724d/attachment.htm


More information about the Squeak-dev mailing list