<html><head></head><body>
<p>Hi Marcel,</p>
<p>Why are you -1 with PromisesLocal? It is easy to add the protocol
published by the current Promise class, minus the wait protocols.
I can certainly rename the proxies, as well. So what specifically
are you -1 abut wrt PromisesLocal? <br/>
</p>
<p>PromisesRemote is in addition to PromisesLocal, it extends
several remote proxies.</p>
<p>K, r<br/>
</p>
<div class="moz-cite-prefix">On 8/3/20 4:21 AM, Marcel Taeumel
wrote:<br/>
</div>
<blockquote type="cite" cite="mid:Mailbird-aed33cae-fbc9-4dec-9aea-463598c7ebc1@hpi.de">
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<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>
<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
<a class="moz-txt-link-rfc2396E" href="mailto:squeak-dev@lists.squeakfoundation.org"><squeak-dev@lists.squeakfoundation.org></a>:</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>
</blockquote>
</body></html>