What would Squeak be like without non-local returns

Rob Withers reefedjib at yahoo.com
Wed Nov 7 17:20:28 UTC 2007

----- Original Message ----- 
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, November 06, 2007 9:38 PM
Subject: Re: What would Squeak be like without non-local returns

> Rob Withers wrote:
>> Well, now I can't find that statement, but I was sure I had read it on 
>> erights or Mark's thesis.  I searched and found nothing.  It may have 
>> been a statement regarding eventual-sending specifically with non-local 
>> return.  It IS strange thinking about the correct behavior of an 
>> expression:
>> object eventual ifTrue: [^3].
>> ^4
>> What should be the result?
> Without any question, 4. Since ifTrue:[] is sent eventual it will return 
> immediately (answering a promise), and the method will continue and return 
> 4. There is absolutely no question about it.
> When the eventual ifTrue: is executed it will barf because it will try to 
> return from a method with no home but that's the way out-of-scope blocks 
> go. It's just as well-defined as a non-local return from an out-of-scope 
> block today, e.g.,
> Foo>>createBlock
>   ^[^self]
> Foo>>callBlock
>   self createBlock value.
> This will simply signal BlockCannotReturn and the eventual ifTrue:[] 
> will - and should - do the same.

This makes that percieved problem of non-local returns with eventual sending 
just go away.  I am totally convinced.

The only difference I have at the moment, is that instead of getting an 
unhandled BlockCannotReturn exception thrown, SqueakElib instead catches the 
exception and resolves the promise for the eventually send #ifTrue: to be a 
broken ref.  Since that promise was never utilized, it quietly goes away - 
it never opens the notifier.  I am torn whether this is the correct thing to 


> Cheers,
>   - Andreas

More information about the Squeak-dev mailing list