xor: and the principle of least surprise

Joerg Beekmann wrote:

Here is something that surprised me. Evaluate each of the following and see if the result is what you would expect. As the subject suggests I was surprised and bitten by the result of the third expression. My expectation was that xor: would treat blocks in the same way as or: and and:.

 

Joerg

 

true and: [true].

true or: [true].

true xor: [true].

I guess I can see what you are saying, but "xor:" is a boolean operator (like | and &), while or: and and: are
have the special feature that they only evaluate the block if its needed to arrive at an answer.  With "xor" you
always need to evaluate both values, so having it omit the block is of no value.

I guess xor: could be better related to max: and min: and pow: etc

 

-- 
Dennis Smith                        [hidden email]
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com

In VW it is:

    xor: aBoolean 
         "Exclusive OR.  Answer true if the receiver is not equivalent to aBoolean."

 

     ^(self == aBoolean) not

 

Because 'true' is not equivalent to a block '[true]', it returns false and then negated true.

 

By the way, in Visual Smalltalk it completely fails because the implementation is:

 

    xor: aBoolean
        "Answer true if the receiver is not equivalent
         to aBoolean, else answer false."
    ^aBoolean not

 

Funny...

 

Alex Ivanov

 

 

 

 

 

 

 

 

 

 -----Original Message-----
From: Joerg Beekmann [mailto:[hidden email]]
Sent: Friday, September 08, 2006 10:46 AM
To: [hidden email]
Subject: xor: and the principle of least surprise

Here is something that surprised me. Evaluate each of the following and see if the result is what you would expect. As the subject suggests I was surprised and bitten by the result of the third expression. My expectation was that xor: would treat blocks in the same way as or: and and:.

 

Joerg

 

true and: [true].

true or: [true].

true xor: [true].

 

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

Travis Griggs wrote:

On Sep 8, 2006, at 10:48, Dennis Smith wrote:

Joerg Beekmann wrote:

Here is something that surprised me. Evaluate each of the following and see if the result is what you would expect. As the subject suggests I was surprised and bitten by the result of the third expression. My expectation was that xor: would treat blocks in the same way as or: and and:.

 

Joerg

 

true and: [true].

true or: [true].

true xor: [true].

I guess I can see what you are saying, but "xor:" is a boolean operator (like | and &), while or: and and: are
have the special feature that they only evaluate the block if its needed to arrive at an answer.  With "xor" you
always need to evaluate both values, so having it omit the block is of no value.

I guess xor: could be better related to max: and min: and pow: etc

It's sooo easy to make it work both ways though. Why not?

xOr: aValuable

^self ~~ aValuable value

Since both blocks and booleans respond appropriately to #value, it just works. If it quacks like a value, it is a value.

But that makes you think its like and: and or: (only evaluation the block if needed), which is not the case, it always
evaluates the block.

--

Travis Griggs

Objologist

One man's blue plane is another man's pink plane.

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

-- 
Dennis Smith                        [hidden email]
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

Dennis Smith wrote:
> Travis Griggs wrote:
>> xOr: aValuable
>> ^self ~~ aValuable value
>>
>> Since both blocks and booleans respond appropriately to #value, it
>> just works. If it quacks like a value, it is a value.
> But that makes you think its like and: and or: (only evaluation the
> block if needed), which is not the case, it always
> evaluates the block.

Strictly speaking, it does evaluate the block only when needed--it's
just that xor always needs that. and: and or: are much more like each
other than xor:, in that xor: can never be short-circuited.


--
Vassili Bykov <[hidden email]>

[:s | s, s printString] value: '[s: | s, s printString] value: '

Well, I think it would be clearer if there were an xor operator instead

of a keyword. Unfortunately, I don’t see anything on my keyboard that

looks like it would read clearly. I suppose we could create a double

symbol operator like ~| to mean xor.

 

Terry

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

---

From: Travis Griggs [mailto:[hidden email]]
Sent: Monday, September 11, 2006 12:24 PM
To: VW NC
Subject: Re: xor: and the principle of least surprise

 

On Sep 8, 2006, at 10:48, Dennis Smith wrote:

Joerg Beekmann wrote:

Here is something that surprised me. Evaluate each of the following and see if the result is what you would expect. As the subject suggests I was surprised and bitten by the result of the third expression. My expectation was that xor: would treat blocks in the same way as or: and and:.

Joerg

true and: [true].

true or: [true].

true xor: [true].

I guess I can see what you are saying, but "xor:" is a boolean operator (like | and &), while or: and and: are
have the special feature that they only evaluate the block if its needed to arrive at an answer. With "xor" you
always need to evaluate both values, so having it omit the block is of no value.

I guess xor: could be better related to max: and min: and pow: etc

 

It's sooo easy to make it work both ways though. Why not?

 

xOr: aValuable

          ^self ~~ aValuable value

 

Since both blocks and booleans respond appropriately to #value, it just works. If it quacks like a value, it is a value.

 

--

Travis Griggs

Objologist

One man's blue plane is another man's pink plane.

 

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

Ditto. It should work with a block param IYAM. Left the way it is, at
least it shouldn't just return true silently.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Joerg Beekmann [mailto:[hidden email]]
Sent: Monday, September 11, 2006 11:43 AM
To: Travis Griggs; VW NC
Subject: RE: xor: and the principle of least surprise

Yes this or something like this is what I would expect. My point was
that xor: looks like a Boolean operator that will take a block as a
parameter. But it doesn't, and worse silently gives what to me was an
unexpected result.

 

 

Joerg

 

 

 

It's sooo easy to make it work both ways though. Why not?

 

xOr: aValuable

          ^self ~~ aValuable value

 

Since both blocks and booleans respond appropriately to #value, it just
works. If it quacks like a value, it is a value.

 

--

Travis Griggs

Objologist

One man's blue plane is another man's pink plane.





 

________________________________

DISCLAIMER: This email is bound by the terms and conditions described at
http://www.key.net/disclaimer.htm