<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi all!<div><br></div><div>I like the idea of fixing Squeak's implementation of promises. However, I am -1 for adding PromiseLocal/PromiseRemote but would rather like to sse am implementation of Promise that works for both cases. Also, "<span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">PromiseERefs" and "BrokenERefs" sounds too cryptic. We can find better names here. :-)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 02.08.2020 15:48:49 schrieb Robert Withers via Squeak-dev <squeak-dev@lists.squeakfoundation.org>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<p>Hello, there,<br>
</p>
<p>In reading the chapter on Promises, in the section on the E
programming language, of which PromisesLocal is modeled, the
following needs clarification:</p>
<blockquote style="min-width: 500px">
<p>Subsequent messages can also be eventually sent to a promise
before it is resolved. In this case, these messages are queued
up and forwarded once the promise is resolved.</p>
</blockquote>
<p>The messages are not queued up at the local promise, pending
forwarding to the eventual result; they are forwarded to a
promise, local to the computation. This is mainly important once
you have introduced remote promises (PromisesRemote). Messages are
sent to the computation and they queue up local, for execution
upon the eventual value, #whenMoreResolved:.</p>
<p>K, r</p>
<p>NB: here is a chained message sending eventually, with Promises.</p>
<blockquote style="min-width: 500px">((10 eventual factorial / 100) * 25)<br>
whenResolved: [:i | i value].<br>
</blockquote>
<br>
<div class="moz-cite-prefix">On 8/2/20 8:55 AM, Robert Withers
wrote:<br>
</div>
<blockquote type="cite" cite="mid:265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me" style="min-width: 500px">
<p>Hi all'y'all!</p>
<p>Here is a textbook on Promises, for your understanding.</p>
<blockquote style="min-width: 500px">[Inspired by functional programming, one of the major
distinctions between different interpretations of this construct
have to do with pipelineing or composition. Some of the more
popular interpretations of futures/promises make it possible to
chain operations, or define a pipeline of operations to be
invoked upon completion of the computation represented by the
future/promise. This is in contrast to callback-heavy or more
imperative direct blocking approaches.]</blockquote>
<div class="" dir="auto">
<div class="ecm0bbzt hv4rvrfc ihqw7lf3 dati1w0a" data-ad-comet-preview="message" data-ad-preview="message" id="jsc_c_j">
<div class="j83agx80 cbu4d94t ew0dbk1b irj2b8pg">
<div class="qzhwtbm6 knvmm38d"><span class="oi732d6d
ik7dh3pa d2edcug0 qv66sw1b c1et5uql a8c37x1j muag1w35
ew0dbk1b jq4qci2q a3bd9o3v knj5qynh oo9gr5id hzawbc8m" dir="auto">
<div class="o9v6fnle cxmmr5t8 oygrvhab hcukyx3x c1et5uql
ii04i59q">
<div dir="auto" style="text-align: start;"><a class="moz-txt-link-freetext" href="http://dist-prog-book.com/chapter/2/futures.html" moz-do-not-send="true">http://dist-prog-book.com/chapter/2/futures.html</a></div>
<div dir="auto" style="text-align: start;">K, r<br>
</div>
<div dir="auto" style="text-align: start;"><br>
</div>
</div>
</span></div>
</div>
</div>
</div>
<div class="moz-cite-prefix">On 8/1/20 12:09 PM, Robert Withers
wrote:<br>
</div>
<blockquote type="cite" cite="mid:7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me" style="min-width: 500px">
<pre class="moz-quote-pre" wrap="">Good afternoon!
I wish to offer a proposal for discussion to include PromisesLocal into
trunk and to replace the implementation of Promise/BrokenPromise with
PromiseERefs and BrokenERefs. The underlying concurrency model has
explicit use of an event loop in PromisesLocal. The code size is minimal
but adds the Promises/A+ specification to Squeak, that can be extended
into a remote reference solution and an Agent communications
architecture. Exceptions are processed.
I want to define a VatSemaphore that allows the user to #wait/#signal,
and they get 'immediate' control flow which most folks find as a valid
way to describe steps taken.Under the covers the VatSemaphore is
connected to the Vat, as an element in a forthcoming continuationPool.
So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the
continuation is captured and placed in the pool and the vat's event loop
continues with the next event. When #signal is sent to this
VatSemaphore, the continuation is scheduled: in the queue and removed
from the pool. The event loop will process the continuation.
</pre>
<blockquote type="cite" style="min-width: 500px">
<blockquote type="cite" style="min-width: 500px">
<pre class="moz-quote-pre" wrap="">On 7/28/20 3:41 PM, Jakob Reschke wrote:
My other suspicion is that we would nevertheless need an extended
debugger to deal well with such eventual control flow. A debugger
with a "step to resolution" or so that steps to the point where the
messages are eventually answered, or the receiver even activated.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think that this is a great idea!
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Research in this direction would be AWESOME!
On 8/1/20 11:39 AM, Robert Withers wrote:
</pre>
<blockquote type="cite" style="min-width: 500px">
<blockquote type="cite" style="min-width: 500px">
<pre class="moz-quote-pre" wrap="">On 7/28/20 3:41 PM, Jakob Reschke wrote:
Current Kernel Promises are also not good at that without sprinkling
breakpoints... This and the dreadful error handling ("well so I
forgot the block argument for the callback again and got an error
from value:, now how do I find out in the debugger which method even
contains my wrong block?!?"
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">What if the debugger could allow you to browse reactor creation
methods? Where is the closure created?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I can imagine an implementation of EIO
(<a class="moz-txt-link-freetext" href="http://wiki.erights.org/wiki/EIO_Redesign" moz-do-not-send="true">http://wiki.erights.org/wiki/EIO_Redesign</a>), Eventual I/O, that has a
#whenAvailable: semantic. Then the UI event loop is just an EInputStream
and we could flip the entire system over to using a promise architecture.
Kindly,
rabbit
</pre>
</blockquote>
</blockquote>
</div></blockquote></div>