["BUG"][FIX?]Incorrect Pseudo-Code for #whileTrue:/#whileFalse:?

Randal L. Schwartz merlyn at stonehenge.com
Mon Jan 1 18:54:34 UTC 2001


>>>>> "Andrew" == Andrew C Greenberg <werdna at mucow.com> writes:

Andrew> It's possible that I'm just not getting it, but it would appear that
Andrew> the pseudo-code for #whileTrue; and #whileFalse: is incorrect.  Even
Andrew> if I were right, it is still the height of pedantry on my part to call
Andrew> this a bug, since the code is never executed due to compiler inlining.
Andrew> Nevertheless, perhaps it would be more aesthetically pleasing to have
Andrew> pseudo-code here that would work if the compiler did not inline loops?

Andrew> The present code in BlockContext is:

>> whileTrue: aBlock
>> "Ordinarily compiled in-line, and therefore not overridable.
>> This is in case the message is sent to other than a literal block.
>> Evaluate the argument, aBlock, as long as the value of the
>> receiver is true."
>> 
>> ^ [self value] whileTrue: [aBlock value]

Andrew> But it would appear to me that this code would infinite loop for so
Andrew> long as these valuations do not result in a walkback.  In either case
Andrew> the behavior appears both undefined and incorrect for most
Andrew> BlockContext instances and arguments.  Perhaps something like the
Andrew> following would yield the desired result?

Andrew> 	^ self value ifTrue: [aBlock value. self whileTrue: aBlock]

Andrew> (and in the case of #whileFalse, use #ifFalse instead).

It's very likely that the author of BlockContext>>whileTrue: knew and
was counting on the compiler to in-line the call, and never call the
method explicitly, *even for* the code in the method!

In that case, the code in the method is executed only for a
#perform:...  and in fact, the code executed is appropriately
optimized.

Your change makes sense if the compiler did not recognize this as a
special case, although it would suffer from recursion trouble if there
was no tail-recursion optimization (which there isn't, if I recall
from the last time I asked about this same thing).

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!





More information about the Squeak-dev mailing list