<html><head></head><body>
<p>Hi all'y'all!</p>
<p>Here is a textbook on Promises, for your understanding.</p>
<blockquote>[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">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">
<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">
<blockquote type="cite">
<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">
<blockquote type="cite">
<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">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>
</body></html>