<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">The term "rejection" is commonly used in other languages, so I'd rather not invent a new term unless we have a good reason.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">- Bert -</div><div class="gmail_extra"><br><div class="gmail_quote">On 14 February 2018 at 11:36, Marcel Taeumel <span dir="ltr"><<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id="m_-5064588619337144130__MailbirdStyleContent" style="font-size:12pt;font-family:calibri;color:#000000">

                                        I forgot the list ... <br><div class="m_-5064588619337144130mb_sig"></div><div class="m_-5064588619337144130history_container"><p>------ Weitergeleitete Nachricht --------<br>Von: Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>><br>Datum: 14.02.2018 11:35:39 <br>Betreff: Re: [ReviewRequest 2] Error-handling and use of `future` <br>An: Tony Garnock-Jones <<a href="mailto:tonyg@leastfixedpoint.com" target="_blank">tonyg@leastfixedpoint.com</a>><br></p><div id="m_-5064588619337144130__MailbirdStyleContent" style="font-size:12pt;font-family:calibri;color:#000000">

                                        Hi Toni,<div><br></div><div>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.</div><div><br></div><div>... #onDelivery: ... #onBreak: ...</div><div><br></div><div>:-)</div><div><br></div><div>Best,</div><div>Marcel</div><div class="m_-5064588619337144130mb_sig"></div>

                                        </div></div>

                                        <blockquote class="m_-5064588619337144130history_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 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <<a href="mailto:tonyg@leastfixedpoint.com" target="_blank">tonyg@leastfixedpoint.com</a>>:</p>Hi Marcel,

<br>

<br>On 02/14/2018 06:58 AM, Marcel Taeumel wrote:

> could elaborate on what it means, in general, to "reject a promise"?

<br>> Does rejection directly map to the exception mechanism? Or are there

<br>> other cases?

<br>

<br>It's terminology lifted from <a href="https://promisesaplus.com/" target="_blank">https://promisesaplus.com/</a>, and it is more

<br>general than the exception mechanism. One advantage of this generality

<br>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.

<br>

<br>Briefly: a promise is a calculation that may yield either a result or a

<br>failure, each with an associated value. A failure value may be any

<br>value, Exception, nil, String, or otherwise. In Squeak, the "resolved"

<br>handlers are notified if the promise yields a result, and the "rejected"

handlers are notified if the promise yields a failure.

<br>

<br>The connection to exceptions is that in most cases a signaled exception

should cause a promise to yield a failure.

<br>

<br>There's a connection in the reverse direction, too: Promise>>#wait will

signal BrokenPromise if a promise yields a failure.

<br>

<br>Rejection is a new-ish (2013?) feature of Squeak promises that doesn't

<br>seem to have been properly integrated; the changes I've been making

<br>recently feel to me like more fully fleshing out the idea. One nice

<br>side-effect of the partiality of the integration of rejection is that

<br>no-one can possibly have been using it :-) leaving us free to assign

sensible semantics to it without fear of backwards-compatibility problems.

<br>

<br>Tony

<br>

                        </blockquote></div><br><br>

<br></blockquote></div><br></div></div>