[squeak-dev] Fw: Re: [ReviewRequest 2] Error-handling and use of `future`

henry henry at callistohouse.club
Fri Feb 16 16:30:07 UTC 2018


I have been working on my code for awhile now, years. My Raven code also provides Promise execution, though the promise returned from an eventual {future} send is also eventual to the resolution, meaning you can also eventually send to the promise of future resolution.

 Raven is distributed so a small actors model is provided: See RemoteHandler. After publishing an object, in one vat-machine, a different vat-machine can obtain a remote promise which eventually resolves to a far reference (see NewFarERef)..

http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz

See PromiseERef. And tests, please.

This allows promise chaining: (42 eventual * 10) hash asString length

I am confused how my code may propagate exceptions thrown when eventually computing. Supposed to Break with BrokenERef and propionate eventually through whenBroken:. Maybe have a default breakReactor for opening the debugger that gets overridden.

How did you implement promise exceptions within the extant promises? Is there any thoughts on integrating this implementation? It derives from http://Erights.org ELib, best as I knew how.

Sent from ProtonMail Mobile

On Thu, Feb 15, 2018 at 14:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Tony,
>
> On Wed, Feb 14, 2018 at 2:36 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>
>> I forgot the list ...
>>
>> ------ Weitergeleitete Nachricht --------
>> Von: Marcel Taeumel <marcel.taeumel at hpi.de>
>> Datum: 14.02.2018 11:35:39
>> Betreff: Re: [ReviewRequest 2] Error-handling and use of `future`
>> An: Tony Garnock-Jones <tonyg at leastfixedpoint.com>
>>
>> Hi Toni,
>>
>> if it is a "promise", why aren't the states "kept" and "broken"? Or "delivered" and "broken"? Well, "resolve" sounds more like message lookup/sending, yet promises do actually make use of that mechanism here.
>>
>> ... #onDelivery: ... #onBreak: ...
>>
>> :-)
>>
>> Best,
>> Marcel
>>
>>> Am 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <tonyg at leastfixedpoint.com>:
>>>
>>> Hi Marcel,
>>>
>>> On 02/14/2018 06:58 AM, Marcel Taeumel wrote:
>>>> could elaborate on what it means, in general, to "reject a promise"?
>>>> Does rejection directly map to the exception mechanism? Or are there
>>>> other cases?
>>>
>>> It's terminology lifted from https://promisesaplus.com/, and it is more
>>> general than the exception mechanism. One advantage of this generality
>>> is that it is able to usefully propagate failures in a concurrent system
>>> in a way that the stack-oriented nature of exception propagation cannot.
>
> One thing to think about is that, because exception handling in Smalltalk is above the VM, exception handling does not have to be limited to a stack-oriented propagation.  There is no reason why promises could not keep track of their creating environments and that exception propagation could be modified to cross promise boundaries, searching for handlers within their originating contexts.
>
> Perhaps this is what the onRejected: mechanism does.  But I've wondered for a few years (without playing, and so my thoughts are vapor and probably quite ill-formed) that such a system could be more convenient.
>
> This line of thought originated in Croquet, which is heavily promise based.  One of the problems in a promise based system is debugging; promises are not easy to relate back to their origin.  With suitable support form the Vm for garbage collection promises appropriately it might be possible to have promises hold onto their originating environments so that when an uncaught exception does occur in a promise one can make sense of its history.  The support needed would include the kind of stack splitting/cloning one sees in Scheme with call/cc where, when a continuation is created the stack is lazily split as either the parent or child continuation returns, frame by frame, leaving the other continuation with a fully formed stack that can be used to understand the computational history.
>
>>> Briefly: a promise is a calculation that may yield either a result or a
>>> failure, each with an associated value. A failure value may be any
>>> value, Exception, nil, String, or otherwise. In Squeak, the "resolved"
>>> handlers are notified if the promise yields a result, and the "rejected"
>>> handlers are notified if the promise yields a failure.
>>>
>>> The connection to exceptions is that in most cases a signaled exception
>>> should cause a promise to yield a failure.
>>>
>>> There's a connection in the reverse direction, too: Promise>>#wait will
>>> signal BrokenPromise if a promise yields a failure.
>>>
>>> Rejection is a new-ish (2013?) feature of Squeak promises that doesn't
>>> seem to have been properly integrated; the changes I've been making
>>> recently feel to me like more fully fleshing out the idea. One nice
>>> side-effect of the partiality of the integration of rejection is that
>>> no-one can possibly have been using it :-) leaving us free to assign
>>> sensible semantics to it without fear of backwards-compatibility problems.
>>>
>>> Tony
>
> --
>
> _,,,^..^,,,_
> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180216/39007c95/attachment.html>


More information about the Squeak-dev mailing list