I think you guys are over complicating this.  Return to a home context
from a future doesn't make any sense and should just toss an error, as
returning to a home context that no longer exist does now.

E style futures are basically some code asking a process somewhere
else to do something, and giving you the ability to attach a callback
for when the other process is finished.  I don't think it make sense
to have the remote code return to some context that isn't in it's
address space, and allowing home context returns in the callback is
certainly a bad idea, as the home context should not still be around
when the callback runs.

On Nov 7, 2007 5:00 AM, Rob Withers <reefedjib at yahoo.com> wrote:
>
> ----- 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
>
>
>