[BUG?] Missing class checks on send| and send& ?

Bijan Parsia bparsia at email.unc.edu
Sat Mar 17 19:07:17 UTC 2001


On Sat, 17 Mar 2001, Mike Rutenberg wrote
> If I evalute the expression
> 	true | 4
> I get back
> 	true
> instead of the error I would expect to get complaining that 4 is not
> boolean.  The same happens for "true & 4".

You're getting bit by the short circuting. #| is defined in True to just
return self.

(In False, it will return the argument, which is bad, since in the case
you've presented it returns 4 instead of false).

So, at the very lest, False>>! should have the check :)

Hmm. Hey! This *isn't* supposed to be short circuting! But the
implementation is (sorta) short circuting, and in a bad way (i.e., adding
this bug).

The comment in Boolean>>1 says:
	"Evaluating disjunction (OR). Evaluate the argument. Then answer
true if either the receiver or the argument is true."
 
That's *not* what's happing. Or that's *sorta* not what's happing. Hmm.

Ok, it's ambiguous. In one sense:

	false | someObject isNil

"evaluates" the second argument. Bah. not *really*, eh? The second
argument is *not* "someObject isNil" but the result thereof. *That* result
isn't checked. For example, try:

	false | [true] "returns the *block*"
	false | [true] value "returns true"

Bad bad, IMHO.

 > Is this intentional, or is it a missing check in the
interpreter? >

As you wrote later, it's not an interpreter issue.

Here's a place where the message passing syntax clashes with the operator
expectations encouraged by the binary selector.

I know! we could add #value to Object and...

WHAM WHAM BAM BAM WHAM WHAM WHAM.

(Excuse me, my better self closed that can of worms ;))

One could check if the result of the argument is evaluable, if so evaluate
it, then either check that result *or* the origianl argumetn for
booleanness.

Hmm. At this point, I suspect that the *right* thing to do is check the
ansi spec...

...ok, it may be *right* but it's also painful (damn Acrocrash).

5.3.3.2 Message: | operand
Synopsis
	Logical or  Boolean disjunction.
Definition: <boolean>
	Return the Boolean disjunction of the receiver and operand. The value
	returned is determined by the following truth table:
  	  |	true    false
	true 	true 	true
	false  	true 	false
Parameters
	operand <boolean> uncaptured
Return Value
	<boolean> unspecified
Errors
	none
--------

I'm not entirely up on interpreting the ANSI spec, but I do no that the
"uncaptured" and "unspecified" stuff can be ignored for our purposes
(dealing with whether the receiver holds onto the argument or createst he
return value, etc.)

No errors are specified, but the value is supposed to be determined by the
truth table.

Dolphin, while putting it under ANSI, does some weird stuff.

VisualWorks, unsurprisingly, does exactly the same thing as
Squeak. Indeed, I'd bet they're the very same code!

I'm not setup to check the Camp Smalltalk ANSI tests, although they may
have thought through this issue.

IOW, a post to camp.lang.smalltalk seems to be in order. If both Dolphin
2.1 and Squeak/VisualWorks are conforming...

er...hold on.

My mistake. Dolphin's #| in True and False are of the Squeak/VW variety,
but in *Boolean* they have:

| operand
	"Answer whether either the receiver OR the <boolean> argument,
	operand, is true.
	Note that a logical expression using #| will evaluate both	
	receiver and argument - use #or: instead for non-evaluating
	expressions, which are generally more efficient."

	^self or: [operand]
----

Weeeeird.

My advice: Don't use | and &!!!

Eeek. Don't try a find senders on #| either, you'll get everythign with
temp variable declarations!!!

On consquence is that #| and #& aren't commutative. 4 | true hits a
#doesNotUnderstand whereas true | 4 is true. *Yuck*. Even if we think of
#| as being true *so long as one of its disjuncts are*, then I think we
should check the argument for truth. But that means putting #| in object
(ick city).

And still dosn't solve the passing a code block or sending *to* a code
block. Ya'd think that "evaluate it's operands" would mean that 
[true] | false would be true. Which it isn't.

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list