Andrew,
"Andrew C. Greenberg" wrote:
<snipped>
I see no virtue in the code as it exists there -- it is semantically confusing and perhaps meaningless outside the context of a special inlining compiler. While the code works, it cannot be explained or understood without reference to the generated bytecodes -- this is not (or perhaps should not be) the Smalltalk way.
What do you think of my suggestion given in an earlier mail in this thread? Do you see a problem here?
Greetings,
Stephan
From VisualWorks® NonCommercial, Release 5i.1 of January 24, 2000:
--- BlockClosure>> whileTrue: aBlock "Evaluate the argument, aBlock, as long as the value of the receiver is true."
^self value ifTrue: [aBlock value. [self value] whileTrue: [aBlock value]]
"This method is inlined if both the receiver and the argument are literal blocks. In all other cases, the code above is run. Note that the code above is defined recursively. However, to avoid actually building an activation record each time this method is invoked recursively, we have used the '[...] whileTrue: [..]' form in the last line, rather than the more concise 'self whileTrue: aBlock'. Using literal blocks for both the receiver and the argument allows the compiler to inline #whileTrue:, which (in the absence of type inferencing) could not be done if we were to use 'self whileTrue: aBlock'." --- This variant avoids recursion if the compiler inlines literal blocks *and* should work without inlining - though very inefficient regarding time and memory (more inefficient than Andrew's suggestion) -, too.
squeak-dev@lists.squeakfoundation.org