Promises

Andreas Rossberg rossberg at google.com
Mon Nov 12 08:31:39 PST 2012


On 7 November 2012 22:19, Mark S. Miller <erights at google.com> wrote:
> 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.

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


More information about the es-discuss mailing list