What would Squeak be like without non-local returns

Rob Withers reefedjib at yahoo.com
Wed Nov 7 04:00:06 UTC 2007


----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>

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

Does it mean this?  Because this violates the rule that there should be no 
blocking.   Msgs should just be sent.  Maybe the rule in play is that 
someBlock does a non-local return that is no longer valid, because it was 
scheduled eventually outside the scope of the method it could return from, 
so it should cause an Error and the return value of doSomeThing: is a broken 
ref.    A way out of this pickle?


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

Ok, but if what I just said holds, then the unwinding terminates where the 
msg was eventually sent and never gets to interact with the sending context.


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

I think that's true.

> 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
> fashion.

Yes, it is not transparent.   On the other hand, any ref could be eventual. 
So the rules for how they behave in various imperative situations are 
important.  As to how to write our example clearly, in the eventual style:

f := object future doSomeThing: someBlock.
f whenResolved: [:fVow |
    a := a + 1.
    fVow doSomeThingElse].

Rob




More information about the Squeak-dev mailing list