Re: [Caml-list] [ANN] Lwt 2.7.0 – monadic promises; concurrent I/O

[Andreas Rossberg <rossberg@mpi-sws.org>]

> On Jan 7, 2017, at 11:56 , Malcolm Matalka <mmatalka@gmail.com> wrote:
> 
> To add some more terminology to the mix, I have generally seen Future
> and Promise being two sides of the same thing.  A Future is a read-only
> value that can be determined to a value and a Promise is the side that
> can be set.  The wikipedia entry uses this terminology.
> 
> https://en.wikipedia.org/wiki/Futures_and_promises

The history of the future/promise terminology is somewhat confusing. Friedman & Wise introduced the concept as promises, Baker & Hewitt (re)named it futures (there are only superficial differences). They gained wider popularity with Multilisp, which also called them futures. As far as the functional language space is concerned, that term pretty much stuck. In the imperative/OO space, the term promise became somewhat popular with Liskov & Shrira and their promise pipelining. However, most contemporary mainstream languages (C++, Java, ...) also use future.

As far as I am aware, Alice ML was the first language that had _both_ futures and promises and factorised them in the way you cite, where promises are essentially single assignment variables — at least I remember that we iterated on various terminologies for a long time around 99/00 until we settled on this. I don’t know how the future/promise API in C++ came about, but it arrived at a very similar distinction. So did Scala. All these languages characterise promises by the presence of a resolve/‘fulfill' operator.

There is a different distinction being made by e.g. Mark Miller, who characterises futures by a (synchronous, blocking) read operation, and promises by a (asynchronous, nonblocking) bind operator taking a callback. Personally, I find this use of terminology rather unintuitive and problematic, since there is no reason that a blocking future cannot also have a non-blocking bind method (and they often do). But it is the reason that JavaScript calls its notion promise (although there was discussion about that). Arguably, though, it is the odd one out as far as both mainstream and functional languages are concerned.

(More generally, I would not recommend using JavaScript as precedent for anything regarding its promises, since they are broken in just about every possible way. And I’m saying that as a member of the committee that standardised them… :) )

/Andreas