The ANSI standard result would be "Orange". This is because each activation
of the outer block creates an independent binding for index  which is then
captured by the inner block when it is created.

Note that most implementations attempt to inline #to:do: and eliminate the
block. So, the result observed for VisualAge is probably an inlining bug.
It appears that when they inline the #to:do: index becomes a local variable
of the enclosing method that gets assigned a value on each iteration of the
loop. A binding to that common variable is captured by each inner block. So
instead of seeing independent argument bindings with independent values
they are all seeing the same variable. When the block is evaluated for the
return value it see the final value assigned to the variable, "Kiwi". The
same thing result would be produced by any other block in the array.

Basically, you can't do this type of optimization if the block argument is
captured by an inner block. VisualWorks and VSE got it right, VisualAge has
a bug.

Allen_Wirfs-Brock at instantiations.com


At 04:16 PM 7/17/99 -0400, Benoit St-Jean wrote:
>At 15:54 99-07-17 -0400, you wrote:
>
>>Non-cute example:
>>
>>| blockArray dataArray |
>>blockArray := Array new: 5.
>>dataArray := #( 'Apple' 'Orange' 'Grape' 'Lemon' 'Kiwi').
>>1 to: blockArray size do: [ :index |
>>	blockArray
>>		at: index
>>		put: [ dataArray at: index ] ].
>>^ (blockArray at: 2) value
>
>I got curious about that code and tried it on several Smalltalk versions.
>Here are the results:
>
>Dolphin : Subscript out of bounds error (Array>>at:)
>Smalltalk Express : primitive fails in Arrat>>at:
>VSE 3.1 : anwers 'Orange'
>VisualWorks 2.5.1 : answers 'Orange'
>VisualWorks Non-Commercial 3.0 : answers 'Orange'
>VisualWorks Beta 5i : raises a SubscriptOutOfBoundsSignal in Core::Array>>at:
>VisualAge for Smalltalk 4.5 : answers 'Kiwi'
>
>Who's right?  :)
>
>What's is the ANSI draft saying about such a case?
>