What would Squeak be like without non-local returns

Igor Stasenko siguctua at gmail.com
Wed Nov 7 01:45:47 UTC 2007

On 07/11/2007, Rob Withers <reefedjib at yahoo.com> wrote:
> ----- 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.

Yeah, but we talking about Smalltalk, not E. Maybe they are bad for E,
but why they should be bad for smalltalk? :)

> > 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?

Ok, lets look again on the problem.
Consider a code:
f := object future doSomeThing: someBlock.
a := a + 1.
f doSomeThingElse.

Semantically, if block (someBlock) does non-local return, that means
that next statements should not be evaluated at all means, because
this could lead to unpredictable behavior.

But there is no ways how to prevent that:
- any piece of code in #doSomeThing: can send a message to object(s)
which lead to execution of non-local returns or throwing an exception
causing stack unwinding.

This means that if you using futures/promises in your code, you can't
make this code to be semantically equivalent as with not using them.
In that way, i think, its better to think of how to prevent obvious
pitfalls and give developer a clear ways how to use eventual refs
safely or teach them (in some manner), that writing a code with
futures is something different than writing same code in imperative

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list