Promises

Mark S. Miller erights at google.com
Wed Nov 7 13:19:03 PST 2012


On Wed, Nov 7, 2012 at 11:12 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 7 November 2012 17:57, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> > While we're talking nomenclature: the terms "promise" and "future" also
> > appear, with roughly the semantics described by Andreas in Scala's API
> [1]
> > and Clojure's API [2] (both very recent APIs). I know MarkM dislikes the
> use
> > of these terms to distinguish synchronization from resolution, as he has
> > long been using those same terms to distinguish traditional "futures",
> which
> > provide a .get() method blocking the calling thread and returning the
> > future's value when ready (as in e.g. Java), from "promises", which only
> > provide a non-blocking "when" or "then" method requiring a callback,
> never
> > blocking the event loop thread (as in all the Javascript promise APIs).
> >
> > To my mind, the term "future" is still very closely tied to blocking
> > synchronization. YMMV.
>
> I see. Interesting, I wasn't aware of Mark's reservations :). Mark, is
> that just about the terminology, or also conceptually?
>
> (Please correct me if I'm wrong, though, IIRC, the original Friedman &
> Wise article introduced the term "promise" for something that's rather
> a future according to that distinction.)
>

It is just terminology. Prior to E, the closest similar system was Liskov &
Shrira's <http://dl.acm.org/citation.cfm?id=54016>, which called them
"promises". All the non-blocking promise systems I am aware of, with the
exception of Tom's AmbientTalk, have called them promises or deferreds.
AFAIK, all are derived from E's promises or Liskov & Shrira's promises. I
think we should respect this history; but history itself is not a strong
argument.

The reason I like the "promise" terminology is that it naturally accounts
for the three main states of a promise: unresolved, fulfilled, and broken.
A major feature of many "promise" systems (including IIRC Liskov and
Shrira's) that I do not recall being implemented by "future" systems (with
the exception of Tom's) is this broken state, as well as the broken
promise contagion rules which go with it.



>
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121107/0db7aae4/attachment.html>


More information about the es-discuss mailing list