At 09:54 AM 4/4/00 +0000, Lex Spoon wrote:
 >...
 >Hmm.  There still seem to be a lot of cases where the compiler *can't*
 >catch it.  For a common example, how would a Smalltalk compiler decide
 >about this one:
 >
 >	someUnknownObject   do: [ :x | ... ]
 >
 >
 >The block is almost definately not captured, because methods called do:
 >rarely capture their block.  But how can a compiler figure this out?  It
 >seems that you would still want to have the dynamic flush-to-heap
 >methods described earlier, so that you can optimistically stack-allocate
 >in cases like this one and then back out of it if the block turns out to
 >get captured.

The issue is not whether the block is captured but whether the block 
references any variables from enclosing scopes. Any such variables will 
have lifetime exceeds that of the block activations and the associated 
method activation and hence must be heap allocated..  In the above example, 
the only variable that is shown is a block argument. Such a variable would 
normally have a lifetime that is the same as the block activation (assuming 
that it is not referenced by any retained nested blocks) so it can be stack 
allocated in the activation record of the block.

If the example had been:
	someMethod
		|captured someUnknownObject|
		someUnknownObject do: [:x| captured someMessage]

Then the method temp named captured could have a lifetime that extends 
beyond the method activation. This variable needs to be heap allocated. 
Note, however, that the variable someUnknownObject isn't "captured" by the 
block so it can be stack allocated in the method's activation record.

Allen_Wirfs-Brock at instantiations.com