On 7 November 2012 22:19, Mark S. Miller <erig...@google.com> wrote: > On Wed, Nov 7, 2012 at 11:12 AM, Andreas Rossberg <rossb...@google.com> > wrote: >> >> On 7 November 2012 17:57, Tom Van Cutsem <tomvc...@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.
I see. Of course, though, in the holder/resolver approach, those states jointly apply to both objects. My reasoning is that in that approach, then, the name "promise" is more suitable for the resolver object, because that's what has the "fulfill" and "fail" methods. The other only has "then"/"when" and friends, which is why a temporal name like "future" is kind of intuitive. But I understand your argument about history and terminology. I can get rather worked up about abuses of pre-established terminology. I don't dare mention my pet peeves on this list. :) > 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. Maybe I misunderstand, but MultiLisp already had a notion of failed future, I think, even if it wasn't really discussed in their paper. It is kind of inevitable once you combine the future (or promise) idea with exceptions. Consequently, it also is part of the future semantics of at least Oz, Alice ML, Scala, and C++. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
