On Wed, Nov 7, 2012 at 11:12 AM, Andreas Rossberg <[email protected]>wrote:
> On 7 November 2012 17:57, Tom Van Cutsem <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
