The term promise was proposed in 1976 by Daniel P. Friedman and David Wise,[1] and Peter Hibbard called it eventual.
[2] A somewhat similar concept future was introduced in 1977 in a paper by Henry Baker and Carl Hewitt.
The original Baker and Hewitt paper described implicit futures, which are naturally supported in the actor model of computation and pure object-oriented programming languages like Smalltalk.
The difficulty is that stock hardware does not deal with futures for primitive data types like integers.
In this case, two complete network round-trips to that machine must take place before the third statement can begin to execute.
Using futures, the above expression could be written which could be expanded to The syntax used here is that of the language E, where x <- a() means to send the message a() asynchronously to x.
All three variables are immediately assigned futures for their results, and execution proceeds to subsequent statements.
The relative latency advantage of pipelining becomes even greater in more complicated situations involving many messages.
In some programming languages such as Oz, E, and AmbientTalk, it is possible to obtain a read-only view of a future, which allows reading its value when resolved, but does not permit resolving it: Support for read-only views is consistent with the principle of least privilege, since it enables the ability to set the value to be restricted to subjects that need to set it.
Then there is a design choice to be made: As an example of the first possibility, in C++11, a thread that needs the value of a future can block until it is available by calling the wait() or get() member functions.
In general, events can be reset to initial empty state and, thus, completed as many times as desired.
A related synchronization construct that can be set multiple times with different values is called an M-var.
In this case it is desirable to return a read-only view to the client, so that only the newly created thread is able to resolve this future.
In programming languages based on threads, the most expressive approach seems to be to provide a mix of non-thread-specific futures, read-only views, and either a WaitNeeded construct, or support for transparent forwarding.
The promise pipelining technique (using futures to overcome latency) was invented by Barbara Liskov and Liuba Shrira in 1988,[6] and independently by Mark S. Miller, Dean Tribble and Rob Jellinghaus in the context of Project Xanadu circa 1989.
[14] The term promise was coined by Liskov and Shrira, although they referred to the pipelining mechanism by the name call-stream, which is now rarely used.
It seems that promises and call-streams were never implemented in any public release of Argus,[15] the programming language used in the Liskov and Shrira paper.
[16] The Xanadu implementation of promise pipelining only became publicly available with the release of the source code for Udanax Gold[17] in 1999, and was never explained in any published document.
[25] This has subsequently been adopted by other languages, notably Dart (2014),[26] Python (2015),[27] Hack (HHVM), and drafts of ECMAScript 7 (JavaScript), Scala, and C++ (2011).
[104][105] This allows futures to be implemented in concurrent programming languages with support for channels, such as CSP and Go.