What would Squeak be like without non-local returns

Rob Withers reefedjib at yahoo.com
Wed Nov 7 01:20:50 UTC 2007

----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, November 06, 2007 4:19 PM
Subject: Re: What would Squeak be like without non-local returns

> On 07/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
>> I'll just throw this out and see what turns up.   As you have probably
>> heard, I am toying with adding eventual refs to Squeak.  Unfortunately, 
>> they
>> don't play well with non-local returns.  Igor and I had been discussing 
>> what
>> could be done with methods having non-local returns adn it is looking 
>> nasty.
>>   So I thought to look at another piece of the puzzle and question its
>> existence.
> I don't think that their existence are questionable.
> Their have own purpose and in example you shown it proves that using
> non-local returns is much more convenient and easier for developer.

Yeah, I agree.  My brain is wired to think that way, cause if it is time to 
exit the method, then go ahead.

> If there are problems between exceptions/non-local returns and
> eventual refs, then they must be solved in one way or another but
> without sacrificing other language features.

E states that non-local returns are bad and we are seeing th implications of 
that statement.  Our candidate solution of mixing non-local returns and 
eventual refs is not pretty.

> When i started my comments about need of special care with any stack
> unwinding operations i just wanted to point that you must take special
> care. It not that easy as removing non-local returns, but its
> solvable. So, i think, a better direction is to find a solution rather
> than looking how to put new feature by removing old one.

I wanted to consider the possibility.  We shouldn't leave rocks unturned.

Knowing we have blocks in play within the execution of a method, we say we 
want to synchronize the execution of the method and not run it eventually. 
How do we do this?


More information about the Squeak-dev mailing list