Bug? Inconsistency?: false ifTrue: [] ==> nil

Andrew C. Greenberg werdna at gate.net
Wed Jan 26 12:58:56 UTC 2000


>Up to now I thought the discussion was pointless, but I think I now see
>what the inconsistency is.
>
>All of these methods do return the block's value that is given as a
>parameter (with nil being the value of an empty block):
>	ifTrue:
>	ifFalse:
>	ifTrue:ifFalse:
>	ifNotNil:
>	ifNil:ifNotNil:
>BUT
>	ifNil:
>does return the receiver (if it is not nil). So this really is an
>inconsistency.

It is different from the proposed specification, but think deeper! 
Is this an "inconsistency," or merely a counterexample to your 
hypothesis that "these methods do return the block's value that is 
given as a parameter (with nil being the value of an empty block)." 
The fact that you list five messages as "evidence" is, in part, 
rhetorical, as only four of these cases address the "empty block 
hypothesis" issue.  Of the four (#ifTrue:,#ifFalse,#ifNil,#ifNotNil), 
one is a counterexample, and one conforms to the hypothesis only 
because of the coincidence that nil == nil.

With all due respect, what you are saying is not that Smalltalk is 
internally consistent, but that it does not conform to ONE given 
specification of the operations.  Significantly, the proposed 
specification is, in fact, incomplete, because it does not describe 
the behavior when the receiver of #ifTrue: and its bretheren is 
non-boolean.  On the other hand, I'm not sure that the given 
specification, when modified to meaningfully catering to ALL cases, 
not just the convenient ones, is more or less elegant than any other, 
nor that it is important given the purpose of the function.  For 
example:

For all of the following messages:

	#ifTrue: #ifFalse: #ifTrue:#ifFalse #ifFalse:ifTrue:

If the receiver is non-boolean, then fail.  If the receiver is 
boolean, then answer the value of the corresponding parameter block 
if there is one, otherwise answer nil.

For all of the following messages:

	#ifNil: #ifNotNil: #ifNil:ifNotNil #ifNotNil:#ifNil:

If the receiver is boolean, then answer the value of the 
corresponding parameter block if there is one, otherwise answer self.

I don't see that any core value of Smalltalk design is being 
fundamentally violated by EITHER specification.  In some ways, trying 
to shoehorn accounting for the nonboolean case into the former seems 
to lead to a less elegant description than the second, but in any 
case, the decision seems more or less arbitrary, and could go one way 
or the other.

Except for the aesthetic parity of #ifTrue: and #ifNil:, given that 
both are pseudovariables, I don't see  any reason for arguing that 
this is a bug, or even an inconsistency.  I might be more likely to 
see the argument more clearly if the booleans were handled by a 
C-like protocol something like:

	#ifTrue:#ifNotTrue: #ifFalse:#ifNotFalse:

For this reason, I see these collections of methods as different, 
alebit similar, things, and not inherently inconsistent.  Indeed, we 
could argue that the protocols for #ifTrue: should have the 
#ifNotTrue options to be consistent with #ifNil:, but I don't see 
that as a good thing.

"A foolish inconsistency is the hobgoblin of little minds."

I think things are OK.  I don't recall, but does ANSI standard 
address this stuff in any way?





More information about the Squeak-dev mailing list