>  The special case when
> this should make a difference is when a block context is created within a
> method and stored in a live object.  Nilling out the sender reference in
> this case prevents the whole sender chain from being kept alive.  (Mike,
> this might be the answer to your earlier question).
> 
> --Vassili

Unfortunately the semantics of the above statement differ between Squeak
& VW since, in Squeak, the block context is created before the block is 
evaluated, and in VW, when it is evaluated.  Both systems, of course, set 
the sender at evaluation time.  Since this is Squeak-list, I'll run with 
that. Besides, capturing the right block context in VW is trickier than
  bc := [ ... ].

When the block context is created, their is no sender.

So, I was about to make the statement:

	"All of this talk about continuations is fine and dandy,
	but shouldn't we work on getting true closures first?"

But, rather, I thought I'd probe Squeak to see how it handled certain
situations...  So I wrote the following method  (Answer is global):
(In Integer, as if it mattered):

foo
	| bc sem  |
	Answer := #noValue.
	bc := [^3].
	sem := Semaphore new.
	[Answer := bc value. sem signal] fork.
	sem wait.
	^bc
		
I evaluated '3 foo'
Now I was expecting Answer to be unchanged (from #noValue), 
and the new process to continue along the original process's sender chain,
leaving the original process waiting forever on an unsignaled semaphore.

But, instead, it crashed the VM.  Oh well.... 

	ANSI X3J20 rev1.9 3.4.5.1 Paragraph 2

says it is undefined. 

-- Mike

'Class new new' fares little better...