[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