What would Squeak be like without non-local returns

>
> ----- Original Message ----- From: "Mathieu Suen"  
> <[hidden email]>
> To: "The general-purpose Squeak developers list" <squeak-
> [hidden email]>
> Sent: Tuesday, November 06, 2007 5:10 PM
> Subject: Re: What would Squeak be like without non-local returns
>
>
>> eventual refs?
>
> This is what I am hoping to build: http://wiki.squeak.org/squeak/6011
> This also describes some of what I was trying to do: http://
> wiki.squeak.org/squeak/2410
>
> The canonical source for this is here: http://www.erights.org.  I  
> am reading Mark Miller's thesis, which is excellent.
>
> Rob
>

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Ralph Johnson
> Sent: Wednesday, November 07, 2007 6:26 AM
> To: The general-purpose Squeak developers list
> Subject: Re: What would Squeak be like without non-local returns
>
> Consider the code
>
> object eventual: [...  ^3]
> ...
> ^4
>
> Depending on the missing code, it could return either 3 or 4.  If not,
> something is very strange, and the language is no longer Smalltalk.
>
> If you get rid of non-local returns, the language is no longer
> Smalltalk.  it might be a good language, but it is not Smalltalk.
>
> -Ralph

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

> Ralph Johnson wrote:
> > Consider the code
> >
> > object eventual: [...  ^3]
> > ...
> > ^4
> >
> > Depending on the missing code, it could return either 3 or 4.  If not,
> > something is very strange, and the language is no longer Smalltalk.
>
> Not at all. Eventual/future sends introduce a new unit of concurrency
> and the only thing we're arguing is whether that second unit of
> concurrency will be executed before the first one. In E/Croquet this is
> not possible, but it is really no different from, e.g.,
>
> Object>>foo
>    [^3] forkAt: Processor activePriority-1.
>    ^4
>
> When you run this, it will return 4 (every time) and fall over the
> non-local return later (every time).

> On 11/7/07, Andreas Raab <[hidden email]> wrote:
> > Ralph Johnson wrote:
> > > Consider the code
> > >
> > > object eventual: [...  ^3]
> > > ...
> > > ^4
> > >
> > > Depending on the missing code, it could return either 3 or 4.  If not,
> > > something is very strange, and the language is no longer Smalltalk.
> >
> > Not at all. Eventual/future sends introduce a new unit of concurrency
> > and the only thing we're arguing is whether that second unit of
> > concurrency will be executed before the first one. In E/Croquet this is
> > not possible, but it is really no different from, e.g.,
> >
> > Object>>foo
> >    [^3] forkAt: Processor activePriority-1.
> >    ^4
> >
> > When you run this, it will return 4 (every time) and fall over the
> > non-local return later (every time).
>
> But that wasn't what I said.  Your code is different from mine.  Note the ...
>
> For example,
>
> Object >>foo
>   [^3] fork.
>   self halt.
>   ^ 4
>
> returns 3.
>

> On 11/7/07, Andreas Raab <[hidden email]> wrote:
>> Ralph Johnson wrote:
>> > Consider the code
>> >
>> > object eventual: [...  ^3]
>> > ...
>> > ^4
>> >
>> > Depending on the missing code, it could return either 3 or 4.  If not,
>> > something is very strange, and the language is no longer Smalltalk.
>>
>> Not at all. Eventual/future sends introduce a new unit of concurrency
>> and the only thing we're arguing is whether that second unit of
>> concurrency will be executed before the first one. In E/Croquet this is
>> not possible, but it is really no different from, e.g.,
>>
>> Object>>foo
>>    [^3] forkAt: Processor activePriority-1.
>>    ^4
>>
>> When you run this, it will return 4 (every time) and fall over the
>> non-local return later (every time).
>
> But that wasn't what I said.  Your code is different from mine.  Note the
> ...
>
> For example,
>
> Object >>foo
>  [^3] fork.
>  self halt.
>  ^ 4
>
> returns 3.

> On 11/7/07, Andreas Raab <[hidden email]> wrote:
>> Ralph Johnson wrote:
>>> Consider the code
>>>
>>> object eventual: [...  ^3]
>>> ...
>>> ^4
>>>
>>> Depending on the missing code, it could return either 3 or 4.  If not,
>>> something is very strange, and the language is no longer Smalltalk.
>> Not at all. Eventual/future sends introduce a new unit of concurrency
>> and the only thing we're arguing is whether that second unit of
>> concurrency will be executed before the first one. In E/Croquet this is
>> not possible, but it is really no different from, e.g.,
>>
>> Object>>foo
>>    [^3] forkAt: Processor activePriority-1.
>>    ^4
>>
>> When you run this, it will return 4 (every time) and fall over the
>> non-local return later (every time).
>
> But that wasn't what I said.  Your code is different from mine.  Note the ...
>
> For example,
>
> Object >>foo
>   [^3] fork.
>   self halt.
>   ^ 4
>
> returns 3.
>
>

>
> ----- Original Message -----
> From: "Igor Stasenko" <[hidden email]>
>
> >> 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
>
>
>

> Igor Stasenko wrote:
> > On 07/11/2007, Andreas Raab <[hidden email]> wrote:
> >> Same answer (though strictly speaking you may get an error that you
> >> can't *wait* in an eventual system).
> > This doesn't change anything, you may put:
> > (1 to: 1000000 atRandom) do: [1+1]
> > instead of delay.
>
> Sure. But it makes no difference. I was only pointing this out for
> completeness.
>
> > Hmm. An example above was to show that when running in parallel there
> > is equal chance to get to ^3 or ^4 first.
>
> No, there isn't. It's simply not how it works. This code cannot run in
> parallel because it's on the same island (necessarily so for non-shared
> state concurrency since blocks have access to receiver variables) and
> can therefore *not* be executed in parallel. The order is completely
> deterministic - scheduling the message in the future *guarantees* that
> it will be executed only after the ^4 has completed. It can't be any
> other way for it to work; if you'd want to run it in parallel you'd need
> to copy it to a different island first in which case the return value
> from the method would *still* be 4! It's completely deterministic, the
> result is 4.
>
> > And in previous message you described behavior, when running code gets
> > to ^4 first. But what if it gets to ^3 first?
>
> It cannot. It simply cannot. If you don't understand why, then you don't
> fully understand how E and Croquet works. The block is created in the
> same island as the receiver. When it is passed to another island (as
> argument to the future ifTrue: message) it will be converted into a
> remote reference. This reference only understands future messages (all
> the immediate messages relate entirely to its role as a reference not
> the underlying object) which is the reason why I distinguished these
> cases in the True>>ifTrue: code (simply because #value on a remote
> reference has no bearing on executing the block that this reference
> points to but scheduling a future value message does).
>
> This in turn means that the second island (the one containing the
> boolean) *must schedule* the future #value with the first island which
> means that the first island will only execute it after the ^4 has been
> executed. It is the *only* way in which this can work in an event-loop
> environment.
>
> What happens is something like here:
>
> Island A:                                     Island B:
> ->message starts running
>   -> aBool future ifTrue:[] ..... -> .....  <schedules True>>ifTrue:>
>   -> Delay wait
>
>                        ... time passes ...
>            <at this point Island A is running the message>
>            <and Island B has the #ifTrue: message scheduled>
>
>                                                -> executes True>>ifTrue:
>    <schedules aBlock value>   ..... <- .....   <- aBlock future value
>                                                -> True>>ifTrue: finishes
>
>                      .... time passes ....
>             <Island A is still not finished with the delay>
>             <Island B has posted the eventual #value to Island A>
>
>   -> Delay wait ends.
>   -> message returns 4
> -> message completes
>
>        <Now, and *only* now the pending #value call will be executed>
>
> -> aBlock value starts
>    -> Attempts to [^3]
>    -> Raises BlockCannotReturn
>
>
> The result is 4. Each and every time.
>
> Cheers,
>   - Andreas
>
>