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

Bob Arning arning at charm.net
Tue Jan 2 14:49:05 UTC 2001

On Tue, 2 Jan 2001 08:10:37 -0500 "Andrew C. Greenberg" <werdna at mucow.com> wrote:
>>  >> 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]
>Still not getting it.  Can someone explain to me how, even on these 
>assumptions, this code can work?  It seems to me that by evaluating 
>self, we reduce the conditional to a boolean, and by evaluating 
>aBlock, we reduce it to whatever its result would be.  While this 
>would excecute properly once, how can it then continue to properly 
>execute the loop?

The method BlockContext>>whileTrue: as written will work IFF it was compiled with the optimization on. In this case the generated bytecodes are:

5 <70> self
6 <C9> send: value
7 <9C> jumpFalse: 13
8 <10> pushTemp: 0
9 <C9> send: value
10 <87> pop
11 <A3 F8> jumpTo: 5
13 <73> pushConstant: nil
14 <7C> returnTop

which basically says:

1. Evaluate the receiver block - "self value" at offsets 5,6
2. If the result of step 1 is false, return <nil> from the method - offsets 7,13,14
3. Evaluate the argument block - offsets 8,9,10
4. GOTO step 1 - offset 11

This has led me to wonder whether it would be better if Smalltalk had (horror of horrors) a GOTO. Since the implementation of this method depends on the fact that the optimized bytecodes emit GOTO, perhaps it would be clearer (and more robust, should someone decide to remove the compiler optimization) if it were actually written that way.


More information about the Squeak-dev mailing list