[BUG?] Missing class checks on send| and send& ?
Richard A. O'Keefe
ok at atlas.otago.ac.nz
Tue Mar 20 00:41:49 UTC 2001
Bijan Parsia <bparsia at email.unc.edu> writes:
(In Lisp):
"The macro and evaluates each form one at a time from left to right. As
soon as any form evaluates to nil, and returns nil without evaluating the
remaining forms. If all forms but the last evaluate to true values, and
returns the results produced by evaluating the last form."
And that's *is* what #& does. However, Boolean>>&s *comment* states:
"Evaluating conjunction. Evaluate the argument. Then answer true if
both the receiver and the argument are true."
Thus the contrast is supposed to be between a short circuting and non
short circuting set of operators.
That *is* precisely the contrast between & and and:.
Note that the method comment for & says nothing about what happens if
the receiver is not true or the argument is not true.
In fact True>>& alternativeObject 's comment says
answer alternativeObject since receiver is true.
We find
True>>
& alternativeObject
^alternativeObject
and: alternativeBlock
^alternativeBlock value
| aBoolean
^self
or: alternativeBlock
^self
False>>
& alternativeObject
^self
and: alternativeBlock
^self
| aBoolean
^aBoolean
or: alternativeBlock
^alternativeBlock value
There is complete consistency here *except* that the argument of
#| should be called alternativeObject, not aBoolean.
If (expr) is free of side effects, then
x & (expr)
x and: [(expr)]
will have the same result, even if (expr)'s result is not a Boolean, and
x | (expr)
x or: [(expr)]
will have the same result, even if (expr)'s result is not a Boolean.
For example,
true & 3 => 3
true and: [3] => 3
false | 42 => 42
false or: [42] => 42
To stick a test in #& or #| without sticking a result test in #and:
or #or: would be to *introduce* an inconsistency.
Side note, I don't like returning *whatever* the last item is, especially
if it's not a boolean (the way lisp does). In the ANSI spec, the return
value of #&/#| is supposed to be defined by the respective truth
tables. Afaik, true and false are the only truth values in Smalltalk (the
other objects do *not* have a Boolean interpretation) which suggests that
true | 4 should be an error. Of course, IIRC, the ANSI spec sorta leaves
this situation undefined, so I guess returning anything is kosher.
It's really a speed/safety tradeoff. Do you want every and: and or: in
the Smalltalk universe to run slower to catch type errors that don't really
seem to be a problem?
More information about the Squeak-dev
mailing list
|