Future, promise, and delay

Future, promise, and delay describe an object that acts as proxy to a result that is initially unknown due to computation of its value, which is yet to be completed. They are normally referred to as constructs used for synchronizing in some concurrent programming language.

Daniel P. Friedman and David Wise proposed the term "promise" in 1975. Peter Hibbard called it "eventual". The term promise was coined by Liskov and Shrira, although they referred to the pipelining mechanism by the name "call-stream". The term promise refers to the fact that in completion of any said operation, an eventual value will be obtained. In the same way, the value can also be taken as eventual because it will only yield out on the occurrence of any event. Thus, both terms refer to the same fact simultaneously.

The terms future, promise, and delay are often used interchangeably. There is some core difference in implementing these terms. Future is revered as the read-only placeholder view of the variable, while promise is a writeable single assignment container that sets the value of the future.

In many cases, future promise are created together. In simple words, future is a value and promise is a function that sets the value. The future reruns the value of an async function (promise); setting the value of future is also called resolving, fulfilling, or binding it.

Promise pipelining

Using future can dramatically reduce the latency in distributed systems; for example, promise enables promise pipelining in programming languages E and Joule, which were also called call-stream in the Argus language.

A note to remember here is that promise pipelining should be distinguished from a parallel asynchronous message passing to a system supporting parallel message passing but not pipelining. It should also not be confused with pipelined message processing in actor systems, where it is possible for an actor to specify and begin executing a behavior for the next message before having completed processing of the current message.

Read-only views

The read-only view allows reading its value when resolved, but doesn't permit you to resolve it, thus making it possible to obtain a read-only view of the future.

The support for read-only views is consistent with the principle of least authority.

The read-only view enables you to set the value to be restricted to the subject that needs to set it. The sender of an asynchronous message (with result) receives the read-only promise for the result, and the target of the message receives the resolver.