{"history":[],"article":{"id":"968d81ba-9213-4f71-8835-b3f02c853372","title":"Futures and promises","slug":"futures-and-promises","content":":::summary\n:::\n\n# \nIn [computer science](https://bliptext.com/articles/computer-science), **future**, **promise**, **delay**, and **deferred** refer to constructs used for [synchronizing](https://bliptext.com/articles/synchronization-computer-science) program [execution](https://bliptext.com/articles/execution-computing) in some [concurrent programming languages](https://bliptext.com/articles/concurrent-programming-language).\nThey describe an object that acts as a proxy for a result that is initially unknown, usually because the [computation](https://bliptext.com/articles/computation) of its value is not yet complete.\nThe term promise was proposed in 1976 by [Daniel P. Friedman](https://bliptext.com/articles/daniel-p-friedman) and David Wise,\nand Peter Hibbard called it eventual.\nA somewhat similar concept future was introduced in 1977 in a paper by [Henry Baker](https://bliptext.com/articles/henry-baker-computer-scientist) and [Carl Hewitt](https://bliptext.com/articles/carl-hewitt).\nThe terms future, promise, delay, and deferred are often used interchangeably, although some differences in usage between future and promise are treated below.\nSpecifically, when usage is distinguished, a future is a read-only placeholder view of a variable, while a promise is a writable, [single assignment](https://bliptext.com/articles/single-assignment) container which sets the value of the future.\nNotably, a future may be defined without specifying which specific promise will set its value, and different possible promises may set the value of a given future, though this can be done only once for a given future.\nIn other cases a future and a promise are created together and associated with each other: the future is the value, the promise is the function that sets the value – essentially the return value (future) of an asynchronous function (promise).\nSetting the value of a future is also called resolving, fulfilling, or binding it.\n\n# Applications\nFutures and promises originated in [functional programming](https://bliptext.com/articles/functional-programming) and related paradigms (such as [logic programming](https://bliptext.com/articles/logic-programming)) to decouple a value (a future) from how it was computed (a promise), allowing the computation to be done more flexibly, notably by parallelizing it.\nLater, it found use in [distributed computing](https://bliptext.com/articles/distributed-computing), in reducing the latency from communication round trips.\nLater still, it gained more use by allowing writing asynchronous programs in [direct style](https://bliptext.com/articles/direct-style), rather than in [continuation-passing style](https://bliptext.com/articles/continuation-passing-style).\n\n# Implicit vs. explicit\nUse of futures may be implicit (any use of the future automatically obtains its value, as if it were an ordinary [reference](https://bliptext.com/articles/reference-programming)) or explicit (the user must call a function to obtain the value, such as the method of in [Java](https://bliptext.com/articles/java-programming-language)).\nObtaining the value of an explicit future can be called stinging or forcing.\nExplicit futures can be implemented as a library, whereas implicit futures are usually implemented as part of the language.\nThe original Baker and Hewitt paper described implicit futures, which are naturally supported in the [actor model](https://bliptext.com/articles/actor-model) of computation and pure [object-oriented programming](https://bliptext.com/articles/object-oriented-programming) languages like [Smalltalk](https://bliptext.com/articles/smalltalk).\nThe Friedman and Wise paper described only explicit futures, probably reflecting the difficulty of efficiently implementing implicit futures on stock hardware.\nThe difficulty is that stock hardware does not deal with futures for primitive data types like integers.\nFor example, an add instruction does not know how to deal with.\nIn pure actor or object languages this problem can be solved by sending the message , which asks the future to add to itself and return the result.\nNote that the message passing approach works regardless of when finishes computation and that no stinging/forcing is needed.\n\n# Promise pipelining\nThe use of futures can dramatically reduce [latency](https://bliptext.com/articles/latency-engineering) in [distributed systems](https://bliptext.com/articles/distributed-computing).\nFor instance, futures enable promise pipelining, as implemented in the languages [E](https://bliptext.com/articles/e-programming-language) and [Joule](https://bliptext.com/articles/joule-programming-language), which was also called call-stream in the language [Argus](https://bliptext.com/articles/argus-programming-language).\nConsider an expression involving conventional [remote procedure calls](https://bliptext.com/articles/remote-procedure-call), such as:\nt3 := ( x.a ).c( y.b )\nwhich could be expanded to t1 := x.a;\nt2 := y.b;\nt3 := t1.c(t2);\nEach statement needs a message to be sent and a reply received before the next statement can proceed.\nSuppose, for example, that, , , and are all located on the same remote machine.\nIn this case, two complete network round-trips to that machine must take place before the third statement can begin to execute.\nThe third statement will then cause yet another round-trip to the same remote machine.\nUsing futures, the above expression could be written\nt3 := (x <- a) <- c(y <- b)\nwhich could be expanded to t1 := x <- a;\nt2 := y <- b;\nt3 := t1 <- c(t2);\nThe syntax used here is that of the language E, where means to send the message asynchronously to.\nAll three variables are immediately assigned futures for their results, and execution proceeds to subsequent statements.\nLater attempts to resolve the value of may cause a delay; however, pipelining can reduce the number of round-trips needed.\nIf, as in the prior example,, , , and are all located on the same remote machine, a pipelined implementation can compute with one round-trip instead of three.\nBecause all three messages are destined for objects which are on the same remote machine, only one request need be sent and only one response need be received containing the result.\nThe send would not block even if and were on different machines to each other, or to or.\nPromise pipelining should be distinguished from parallel asynchronous message passing.\nIn a system supporting parallel message passing but not pipelining, the message sends and in the above example could proceed in parallel, but the send of would have to wait until both and had been received, even when , , , and are on the same remote machine.\nThe relative latency advantage of pipelining becomes even greater in more complicated situations involving many messages.\nPromise pipelining also should not be confused with [pipelined message processing](https://bliptext.com/articles/actor-model) in actor systems, where it is possible for an actor to specify and begin executing a behaviour for the next message before having completed processing of the current message.\n\n# Read-only views\nIn some programming languages such as [Oz](https://bliptext.com/articles/oz-programming-language), [E](https://bliptext.com/articles/e-programming-language), and [AmbientTalk](https://bliptext.com/articles/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:\nSupport for read-only views is consistent with the [principle of least privilege](https://bliptext.com/articles/principle-of-least-privilege), since it enables the ability to set the value to be restricted to [subjects](https://bliptext.com/articles/subject-access-control) that need to set it.\nIn a system that also supports pipelining, 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.\n\n# Thread-specific futures\nSome languages, such as [Alice ML](https://bliptext.com/articles/alice-programming-language), define futures that are associated with a specific thread that computes the future's value.\nThis computation can start either [eagerly](https://bliptext.com/articles/eager-evaluation) when the future is created, or [lazily](https://bliptext.com/articles/lazy-evaluation) when its value is first needed.\nA lazy future is similar to a [thunk](https://bliptext.com/articles/thunk-functional-programming), in the sense of a delayed computation.\nAlice ML also supports futures that can be resolved by any thread, and calls these promises.\nThis use of promise is different from its use in E as described [above](https://bliptext.com/articles/).\nIn Alice, a promise is not a read-only view, and promise pipelining is unsupported.\nInstead, pipelining naturally happens for futures, including ones associated with promises.\n\n# Blocking vs non-blocking semantics\nIf the value of a future is accessed asynchronously, for example by sending a message to it, or by explicitly waiting for it using a construct such as in E, then there is no difficulty in delaying until the future is resolved before the message can be received or the wait completes.\nThis is the only case to be considered in purely asynchronous systems such as pure actor languages.\nHowever, in some systems it may also be possible to attempt to immediately or synchronously access a future's value.\nThen there is a design choice to be made:\nAs an example of the first possibility, in [C++11](https://bliptext.com/articles/c-11), a thread that needs the value of a future can block until it is available by calling the or member functions.\nA timeout can also be specified on the wait using the or member functions to avoid indefinite blocking.\nIf the future arose from a call to then a blocking wait (without a timeout) may cause synchronous invocation of the function to compute the result on the waiting thread.\n\n# Related constructs\nFutures are a particular case of the [synchronization primitive](https://bliptext.com/articles/synchronization-primitive) \"[events](https://bliptext.com/articles/event-synchronization-primitive),\" which can be completed only once.\nIn general, events can be reset to initial empty state and, thus, completed as many times as desired.\nAn I-var (as in the language [Id](https://bliptext.com/articles/id-programming-language)) is a future with blocking semantics as defined above.\nAn I-structure is a [data structure](https://bliptext.com/articles/data-structure) containing I-vars.\nA related synchronization construct that can be set multiple times with different values is called an M-var.\nM-vars support atomic operations to take or put the current value, where taking the value also sets the M-var back to its initial empty state.\nA concurrent logic variable is similar to a future, but is updated by [unification](https://bliptext.com/articles/unification-computing), in the same way as logic variables in [logic programming](https://bliptext.com/articles/logic-programming).\nThus it can be bound more than once to unifiable values, but cannot be set back to an empty or unresolved state.\nThe dataflow variables of Oz act as concurrent logic variables, and also have blocking semantics as mentioned above.\nA concurrent constraint variable is a generalization of concurrent logic variables to support [constraint logic programming](https://bliptext.com/articles/constraint-logic-programming): the constraint may be narrowed multiple times, indicating smaller sets of possible values.\nTypically there is a way to specify a thunk that should run whenever the constraint is narrowed further; this is needed to support constraint propagation.\n\n# Relations between the expressiveness of different forms of future\nEager thread-specific futures can be straightforwardly implemented in non-thread-specific futures, by creating a thread to calculate the value at the same time as creating the future.\nIn 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.\nTo implement implicit lazy thread-specific futures (as provided by Alice ML, for example) in terms in non-thread-specific futures, needs a mechanism to determine when the future's value is first needed (for example, the construct in Oz ).\nIf all values are objects, then the ability to implement transparent forwarding objects is sufficient, since the first message sent to the forwarder indicates that the future's value is needed.\nNon-thread-specific futures can be implemented in thread-specific futures, assuming that the system supports message passing, by having the resolving thread send a message to the future's own thread.\nHowever, this can be viewed as unneeded complexity.\nIn 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.\n\n# Evaluation strategy\nThe [evaluation strategy](https://bliptext.com/articles/evaluation-strategy) of futures, which may be termed [call by future](https://bliptext.com/articles/call-by-future), is non-deterministic: the value of a future will be evaluated at some time between when the future is created and when its value is used, but the precise time is not determined beforehand and can change from run to run.\nThe computation can start as soon as the future is created ([eager evaluation](https://bliptext.com/articles/eager-evaluation)) or only when the value is actually needed ([lazy evaluation](https://bliptext.com/articles/lazy-evaluation)), and may be suspended part-way through, or executed in one run.\nOnce the value of a future is assigned, it is not recomputed on future accesses; this is like the [memoization](https://bliptext.com/articles/memoization) used in [call by need](https://bliptext.com/articles/call-by-need).\n****A**** **** ****i****s**** ****a**** ****f****u****t****u****r****e**** ****t****h****a****t**** ****d****e****t****e****r****m****i****n****i****s****t****i****c****a****l****l****y**** ****h****a****s**** ****l****a****z****y**** ****e****v****a****l****u****a****t****i****o****n**** ****s****e****m****a****n****t****i****c****s****:**** ****t****h****e**** ****c****o****m****p****u****t****a****t****i****o****n**** ****o****f**** ****t****h****e**** ****f****u****t****u****r****e****'****s**** ****v****a****l****u****e**** ****s****t****a****r****t****s**** ****w****h****e****n**** ****t****h****e**** ****v****a****l****u****e**** ****i****s**** ****f****i****r****s****t**** ****n****e****e****d****e****d****,**** ****a****s**** ****i****n**** ****c****a****l****l**** ****b****y**** ****n****e****e****d****.****\nLazy futures are of use in languages which evaluation strategy is by default not lazy.\nFor example, in [C++11](https://bliptext.com/articles/c-11) such lazy futures can be created by passing the launch policy to , along with the function to compute the value.\n\n# Semantics of futures in the actor model\nIn the actor model, an expression of the form is defined by how it responds to an message with environment E and customer C as follows: The future expression responds to the message by sending the customer C a newly created actor F (the proxy for the response of evaluating ) as a return value concurrently with sending an message with environment E and customer C.\nThe default behavior of F is as follows:\nHowever, some futures can deal with requests in special ways to provide greater parallelism.\nFor example, the expression can create a new future that will behave like the number.\nThis trick does not always work.\nFor example, the following conditional expression:\nsuspends until the future for has responded to the request asking if is greater than itself.\n\n# History\nThe future and/or promise constructs were first implemented in programming languages such as [MultiLisp](https://bliptext.com/articles/multilisp) and [Act 1](https://bliptext.com/articles/actor-model).\nThe use of logic variables for communication in [concurrent](https://bliptext.com/articles/concurrency-computer-science) [logic programming](https://bliptext.com/articles/logic-programming) languages was quite similar to futures.\nThese began in [Prolog](https://bliptext.com/articles/prolog) with Freeze and IC [Prolog](https://bliptext.com/articles/prolog), and became a true concurrency primitive with Relational Language, Concurrent [Prolog](https://bliptext.com/articles/prolog), guarded [Horn clauses](https://bliptext.com/articles/horn-clause) (GHC), [Parlog](https://bliptext.com/articles/parlog), [Strand](https://bliptext.com/articles/strand-programming-language), [Vulcan](https://bliptext.com/articles/vulcan-programming-language), [Janus](https://bliptext.com/articles/janus-concurrent-constraint-programming-language), [Oz-Mozart](https://bliptext.com/articles/oz-programming-language), [Flow Java](https://bliptext.com/articles/flow-java), and [Alice ML](https://bliptext.com/articles/alice-programming-language).\nThe single-assignment I-var from [dataflow programming](https://bliptext.com/articles/dataflow-programming) languages, originating in [Id](https://bliptext.com/articles/id-programming-language) and included in Reppy's [Concurrent ML](https://bliptext.com/articles/concurrent-ml), is much like the concurrent logic variable.\nThe promise pipelining technique (using futures to overcome latency) was invented by [Barbara Liskov](https://bliptext.com/articles/barbara-liskov) and [Liuba Shrira](https://bliptext.com/articles/liuba-shrira) in 1988, and independently by [Mark S. Miller](https://bliptext.com/articles/mark-s-miller), Dean Tribble and Rob Jellinghaus in the context of [Project Xanadu](https://bliptext.com/articles/project-xanadu) circa 1989.\nThe 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.\nBoth the design described in Liskov and Shrira's paper, and the implementation of promise pipelining in Xanadu, had the limit that promise values were not [first-class](https://bliptext.com/articles/first-class-value): an argument to, or the value returned by a call or send could not directly be a promise (so the example of promise pipelining given earlier, which uses a promise for the result of one send as an argument to another, would not have been directly expressible in the call-stream design or in the Xanadu implementation).\nIt seems that promises and call-streams were never implemented in any public release of Argus, the programming language used in the Liskov and Shrira paper.\nArgus development stopped around 1988.\nThe Xanadu implementation of promise pipelining only became publicly available with the release of the source code for Udanax Gold in 1999, and was never explained in any published document.\nThe later implementations in Joule and E support fully first-class promises and resolvers.\nSeveral early actor languages, including the Act series, supported both parallel message passing and pipelined message processing, but not promise pipelining.\n(Although it is technically possible to implement the last of these features in the first two, there is no evidence that the Act languages did so.)\nAfter 2000, a major revival of interest in futures and promises occurred, due to their use in [responsiveness](https://bliptext.com/articles/responsiveness) of user interfaces, and in [web development](https://bliptext.com/articles/web-development), due to the [request–response](https://bliptext.com/articles/request-response) model of message-passing.\nSeveral mainstream languages now have language support for futures and promises, most notably popularized by in Java 5 (announced 2004) and the [async/await](https://bliptext.com/articles/async-await) constructions in .NET 4.5 (announced 2010, released 2012) largely inspired by the asynchronous workflows of F#, which dates to 2007.\nThis has subsequently been adopted by other languages, notably Dart (2014), Python (2015), Hack (HHVM), and drafts of ECMAScript 7 (JavaScript), Scala, and C++ (2011).\n\n# List of implementations\nSome programming languages are supporting futures, promises, concurrent logic variables, dataflow variables, or I-vars, either by direct language support or in the standard library.\n\n## List of concepts related to futures and promises by programming language\nLanguages also supporting promise pipelining include:\n\n## List of library-based implementations of futures\n\n## Coroutines\nFutures can be implemented in [coroutines](https://bliptext.com/articles/coroutine) or [generators](https://bliptext.com/articles/generator-computer-programming), resulting in the same evaluation strategy (e.g., cooperative multitasking or lazy evaluation).\n\n## Channels\nFutures can easily be implemented in [channels](https://bliptext.com/articles/channel-programming): a future is a one-element channel, and a promise is a process that sends to the channel, fulfilling the future.\nThis allows futures to be implemented in concurrent programming languages with support for channels, such as CSP and [Go](https://bliptext.com/articles/go-programming-language).\nThe resulting futures are explicit, as they must be accessed by reading from the channel, rather than only evaluation.","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-25T21:47:38.721Z","updated_at":"2025-01-25T21:47:38.721Z","search_vector":"'futur':1 'promis':3","search_content":" \n \n\n# \nIn [computer science](https://bliptext.com/articles/computer-science), **future**, **promise**, **delay**, and **deferred** refer to constructs used for [synchronizing](https://bliptext.com/articles/synchronization-computer-science) program [execution](https://bliptext.com/articles/execution-computing) in some [concurrent programming languages](https://bliptext.com/articles/concurrent-programming-language).\nThey describe an object that acts as a proxy for a result that is initially unknown, usually because the [computation](https://bliptext.com/articles/computation) of its value is not yet complete.\nThe term promise was proposed in 1976 by [Daniel P. Friedman](https://bliptext.com/articles/daniel-p-friedman) and David Wise,\nand Peter Hibbard called it eventual.\nA somewhat similar concept future was introduced in 1977 in a paper by [Henry Baker](https://bliptext.com/articles/henry-baker-computer-scientist) and [Carl Hewitt](https://bliptext.com/articles/carl-hewitt).\nThe terms future, promise, delay, and deferred are often used interchangeably, although some differences in usage between future and promise are treated below.\nSpecifically, when usage is distinguished, a future is a read-only placeholder view of a variable, while a promise is a writable, [single assignment](https://bliptext.com/articles/single-assignment) container which sets the value of the future.\nNotably, a future may be defined without specifying which specific promise will set its value, and different possible promises may set the value of a given future, though this can be done only once for a given future.\nIn other cases a future and a promise are created together and associated with each other: the future is the value, the promise is the function that sets the value – essentially the return value (future) of an asynchronous function (promise).\nSetting the value of a future is also called resolving, fulfilling, or binding it.\n\n# Applications\nFutures and promises originated in [functional programming](https://bliptext.com/articles/functional-programming) and related paradigms (such as [logic programming](https://bliptext.com/articles/logic-programming)) to decouple a value (a future) from how it was computed (a promise), allowing the computation to be done more flexibly, notably by parallelizing it.\nLater, it found use in [distributed computing](https://bliptext.com/articles/distributed-computing), in reducing the latency from communication round trips.\nLater still, it gained more use by allowing writing asynchronous programs in [direct style](https://bliptext.com/articles/direct-style), rather than in [continuation-passing style](https://bliptext.com/articles/continuation-passing-style).\n\n# Implicit vs. explicit\nUse of futures may be implicit (any use of the future automatically obtains its value, as if it were an ordinary [reference](https://bliptext.com/articles/reference-programming)) or explicit (the user must call a function to obtain the value, such as the method of in [Java](https://bliptext.com/articles/java-programming-language)).\nObtaining the value of an explicit future can be called stinging or forcing.\nExplicit futures can be implemented as a library, whereas implicit futures are usually implemented as part of the language.\nThe original Baker and Hewitt paper described implicit futures, which are naturally supported in the [actor model](https://bliptext.com/articles/actor-model) of computation and pure [object-oriented programming](https://bliptext.com/articles/object-oriented-programming) languages like [Smalltalk](https://bliptext.com/articles/smalltalk).\nThe Friedman and Wise paper described only explicit futures, probably reflecting the difficulty of efficiently implementing implicit futures on stock hardware.\nThe difficulty is that stock hardware does not deal with futures for primitive data types like integers.\nFor example, an add instruction does not know how to deal with.\nIn pure actor or object languages this problem can be solved by sending the message , which asks the future to add to itself and return the result.\nNote that the message passing approach works regardless of when finishes computation and that no stinging/forcing is needed.\n\n# Promise pipelining\nThe use of futures can dramatically reduce [latency](https://bliptext.com/articles/latency-engineering) in [distributed systems](https://bliptext.com/articles/distributed-computing).\nFor instance, futures enable promise pipelining, as implemented in the languages [E](https://bliptext.com/articles/e-programming-language) and [Joule](https://bliptext.com/articles/joule-programming-language), which was also called call-stream in the language [Argus](https://bliptext.com/articles/argus-programming-language).\nConsider an expression involving conventional [remote procedure calls](https://bliptext.com/articles/remote-procedure-call), such as:\nt3 := ( x.a ).c( y.b )\nwhich could be expanded to t1 := x.a;\nt2 := y.b;\nt3 := t1.c(t2);\nEach statement needs a message to be sent and a reply received before the next statement can proceed.\nSuppose, for example, that, , , and are all located on the same remote machine.\nIn this case, two complete network round-trips to that machine must take place before the third statement can begin to execute.\nThe third statement will then cause yet another round-trip to the same remote machine.\nUsing futures, the above expression could be written\nt3 := (x <- a) <- c(y <- b)\nwhich could be expanded to t1 := x <- a;\nt2 := y <- b;\nt3 := t1 <- c(t2);\nThe syntax used here is that of the language E, where means to send the message asynchronously to.\nAll three variables are immediately assigned futures for their results, and execution proceeds to subsequent statements.\nLater attempts to resolve the value of may cause a delay; however, pipelining can reduce the number of round-trips needed.\nIf, as in the prior example,, , , and are all located on the same remote machine, a pipelined implementation can compute with one round-trip instead of three.\nBecause all three messages are destined for objects which are on the same remote machine, only one request need be sent and only one response need be received containing the result.\nThe send would not block even if and were on different machines to each other, or to or.\nPromise pipelining should be distinguished from parallel asynchronous message passing.\nIn a system supporting parallel message passing but not pipelining, the message sends and in the above example could proceed in parallel, but the send of would have to wait until both and had been received, even when , , , and are on the same remote machine.\nThe relative latency advantage of pipelining becomes even greater in more complicated situations involving many messages.\nPromise pipelining also should not be confused with [pipelined message processing](https://bliptext.com/articles/actor-model) in actor systems, where it is possible for an actor to specify and begin executing a behaviour for the next message before having completed processing of the current message.\n\n# Read-only views\nIn some programming languages such as [Oz](https://bliptext.com/articles/oz-programming-language), [E](https://bliptext.com/articles/e-programming-language), and [AmbientTalk](https://bliptext.com/articles/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:\nSupport for read-only views is consistent with the [principle of least privilege](https://bliptext.com/articles/principle-of-least-privilege), since it enables the ability to set the value to be restricted to [subjects](https://bliptext.com/articles/subject-access-control) that need to set it.\nIn a system that also supports pipelining, 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.\n\n# Thread-specific futures\nSome languages, such as [Alice ML](https://bliptext.com/articles/alice-programming-language), define futures that are associated with a specific thread that computes the future's value.\nThis computation can start either [eagerly](https://bliptext.com/articles/eager-evaluation) when the future is created, or [lazily](https://bliptext.com/articles/lazy-evaluation) when its value is first needed.\nA lazy future is similar to a [thunk](https://bliptext.com/articles/thunk-functional-programming), in the sense of a delayed computation.\nAlice ML also supports futures that can be resolved by any thread, and calls these promises.\nThis use of promise is different from its use in E as described [above](https://bliptext.com/articles/).\nIn Alice, a promise is not a read-only view, and promise pipelining is unsupported.\nInstead, pipelining naturally happens for futures, including ones associated with promises.\n\n# Blocking vs non-blocking semantics\nIf the value of a future is accessed asynchronously, for example by sending a message to it, or by explicitly waiting for it using a construct such as in E, then there is no difficulty in delaying until the future is resolved before the message can be received or the wait completes.\nThis is the only case to be considered in purely asynchronous systems such as pure actor languages.\nHowever, in some systems it may also be possible to attempt to immediately or synchronously access a future's value.\nThen there is a design choice to be made:\nAs an example of the first possibility, in [C++11](https://bliptext.com/articles/c-11), a thread that needs the value of a future can block until it is available by calling the or member functions.\nA timeout can also be specified on the wait using the or member functions to avoid indefinite blocking.\nIf the future arose from a call to then a blocking wait (without a timeout) may cause synchronous invocation of the function to compute the result on the waiting thread.\n\n# Related constructs\nFutures are a particular case of the [synchronization primitive](https://bliptext.com/articles/synchronization-primitive) \"[events](https://bliptext.com/articles/event-synchronization-primitive),\" which can be completed only once.\nIn general, events can be reset to initial empty state and, thus, completed as many times as desired.\nAn I-var (as in the language [Id](https://bliptext.com/articles/id-programming-language)) is a future with blocking semantics as defined above.\nAn I-structure is a [data structure](https://bliptext.com/articles/data-structure) containing I-vars.\nA related synchronization construct that can be set multiple times with different values is called an M-var.\nM-vars support atomic operations to take or put the current value, where taking the value also sets the M-var back to its initial empty state.\nA concurrent logic variable is similar to a future, but is updated by [unification](https://bliptext.com/articles/unification-computing), in the same way as logic variables in [logic programming](https://bliptext.com/articles/logic-programming).\nThus it can be bound more than once to unifiable values, but cannot be set back to an empty or unresolved state.\nThe dataflow variables of Oz act as concurrent logic variables, and also have blocking semantics as mentioned above.\nA concurrent constraint variable is a generalization of concurrent logic variables to support [constraint logic programming](https://bliptext.com/articles/constraint-logic-programming): the constraint may be narrowed multiple times, indicating smaller sets of possible values.\nTypically there is a way to specify a thunk that should run whenever the constraint is narrowed further; this is needed to support constraint propagation.\n\n# Relations between the expressiveness of different forms of future\nEager thread-specific futures can be straightforwardly implemented in non-thread-specific futures, by creating a thread to calculate the value at the same time as creating the future.\nIn 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.\nTo implement implicit lazy thread-specific futures (as provided by Alice ML, for example) in terms in non-thread-specific futures, needs a mechanism to determine when the future's value is first needed (for example, the construct in Oz ).\nIf all values are objects, then the ability to implement transparent forwarding objects is sufficient, since the first message sent to the forwarder indicates that the future's value is needed.\nNon-thread-specific futures can be implemented in thread-specific futures, assuming that the system supports message passing, by having the resolving thread send a message to the future's own thread.\nHowever, this can be viewed as unneeded complexity.\nIn 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.\n\n# Evaluation strategy\nThe [evaluation strategy](https://bliptext.com/articles/evaluation-strategy) of futures, which may be termed [call by future](https://bliptext.com/articles/call-by-future), is non-deterministic: the value of a future will be evaluated at some time between when the future is created and when its value is used, but the precise time is not determined beforehand and can change from run to run.\nThe computation can start as soon as the future is created ([eager evaluation](https://bliptext.com/articles/eager-evaluation)) or only when the value is actually needed ([lazy evaluation](https://bliptext.com/articles/lazy-evaluation)), and may be suspended part-way through, or executed in one run.\nOnce the value of a future is assigned, it is not recomputed on future accesses; this is like the [memoization](https://bliptext.com/articles/memoization) used in [call by need](https://bliptext.com/articles/call-by-need).\n****A**** **** ****i****s**** ****a**** ****f****u****t****u****r****e**** ****t****h****a****t**** ****d****e****t****e****r****m****i****n****i****s****t****i****c****a****l****l****y**** ****h****a****s**** ****l****a****z****y**** ****e****v****a****l****u****a****t****i****o****n**** ****s****e****m****a****n****t****i****c****s****:**** ****t****h****e**** ****c****o****m****p****u****t****a****t****i****o****n**** ****o****f**** ****t****h****e**** ****f****u****t****u****r****e****'****s**** ****v****a****l****u****e**** ****s****t****a****r****t****s**** ****w****h****e****n**** ****t****h****e**** ****v****a****l****u****e**** ****i****s**** ****f****i****r****s****t**** ****n****e****e****d****e****d****,**** ****a****s**** ****i****n**** ****c****a****l****l**** ****b****y**** ****n****e****e****d****.****\nLazy futures are of use in languages which evaluation strategy is by default not lazy.\nFor example, in [C++11](https://bliptext.com/articles/c-11) such lazy futures can be created by passing the launch policy to , along with the function to compute the value.\n\n# Semantics of futures in the actor model\nIn the actor model, an expression of the form is defined by how it responds to an message with environment E and customer C as follows: The future expression responds to the message by sending the customer C a newly created actor F (the proxy for the response of evaluating ) as a return value concurrently with sending an message with environment E and customer C.\nThe default behavior of F is as follows:\nHowever, some futures can deal with requests in special ways to provide greater parallelism.\nFor example, the expression can create a new future that will behave like the number.\nThis trick does not always work.\nFor example, the following conditional expression:\nsuspends until the future for has responded to the request asking if is greater than itself.\n\n# History\nThe future and/or promise constructs were first implemented in programming languages such as [MultiLisp](https://bliptext.com/articles/multilisp) and [Act 1](https://bliptext.com/articles/actor-model).\nThe use of logic variables for communication in [concurrent](https://bliptext.com/articles/concurrency-computer-science) [logic programming](https://bliptext.com/articles/logic-programming) languages was quite similar to futures.\nThese began in [Prolog](https://bliptext.com/articles/prolog) with Freeze and IC [Prolog](https://bliptext.com/articles/prolog), and became a true concurrency primitive with Relational Language, Concurrent [Prolog](https://bliptext.com/articles/prolog), guarded [Horn clauses](https://bliptext.com/articles/horn-clause) (GHC), [Parlog](https://bliptext.com/articles/parlog), [Strand](https://bliptext.com/articles/strand-programming-language), [Vulcan](https://bliptext.com/articles/vulcan-programming-language), [Janus](https://bliptext.com/articles/janus-concurrent-constraint-programming-language), [Oz-Mozart](https://bliptext.com/articles/oz-programming-language), [Flow Java](https://bliptext.com/articles/flow-java), and [Alice ML](https://bliptext.com/articles/alice-programming-language).\nThe single-assignment I-var from [dataflow programming](https://bliptext.com/articles/dataflow-programming) languages, originating in [Id](https://bliptext.com/articles/id-programming-language) and included in Reppy's [Concurrent ML](https://bliptext.com/articles/concurrent-ml), is much like the concurrent logic variable.\nThe promise pipelining technique (using futures to overcome latency) was invented by [Barbara Liskov](https://bliptext.com/articles/barbara-liskov) and [Liuba Shrira](https://bliptext.com/articles/liuba-shrira) in 1988, and independently by [Mark S. Miller](https://bliptext.com/articles/mark-s-miller), Dean Tribble and Rob Jellinghaus in the context of [Project Xanadu](https://bliptext.com/articles/project-xanadu) circa 1989.\nThe 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.\nBoth the design described in Liskov and Shrira's paper, and the implementation of promise pipelining in Xanadu, had the limit that promise values were not [first-class](https://bliptext.com/articles/first-class-value): an argument to, or the value returned by a call or send could not directly be a promise (so the example of promise pipelining given earlier, which uses a promise for the result of one send as an argument to another, would not have been directly expressible in the call-stream design or in the Xanadu implementation).\nIt seems that promises and call-streams were never implemented in any public release of Argus, the programming language used in the Liskov and Shrira paper.\nArgus development stopped around 1988.\nThe Xanadu implementation of promise pipelining only became publicly available with the release of the source code for Udanax Gold in 1999, and was never explained in any published document.\nThe later implementations in Joule and E support fully first-class promises and resolvers.\nSeveral early actor languages, including the Act series, supported both parallel message passing and pipelined message processing, but not promise pipelining.\n(Although it is technically possible to implement the last of these features in the first two, there is no evidence that the Act languages did so.)\nAfter 2000, a major revival of interest in futures and promises occurred, due to their use in [responsiveness](https://bliptext.com/articles/responsiveness) of user interfaces, and in [web development](https://bliptext.com/articles/web-development), due to the [request–response](https://bliptext.com/articles/request-response) model of message-passing.\nSeveral mainstream languages now have language support for futures and promises, most notably popularized by in Java 5 (announced 2004) and the [async/await](https://bliptext.com/articles/async-await) constructions in .NET 4.5 (announced 2010, released 2012) largely inspired by the asynchronous workflows of F#, which dates to 2007.\nThis has subsequently been adopted by other languages, notably Dart (2014), Python (2015), Hack (HHVM), and drafts of ECMAScript 7 (JavaScript), Scala, and C++ (2011).\n\n# List of implementations\nSome programming languages are supporting futures, promises, concurrent logic variables, dataflow variables, or I-vars, either by direct language support or in the standard library.\n\n## List of concepts related to futures and promises by programming language\nLanguages also supporting promise pipelining include:\n\n## List of library-based implementations of futures\n\n## Coroutines\nFutures can be implemented in [coroutines](https://bliptext.com/articles/coroutine) or [generators](https://bliptext.com/articles/generator-computer-programming), resulting in the same evaluation strategy (e.g., cooperative multitasking or lazy evaluation).\n\n## Channels\nFutures can easily be implemented in [channels](https://bliptext.com/articles/channel-programming): a future is a one-element channel, and a promise is a process that sends to the channel, fulfilling the future.\nThis allows futures to be implemented in concurrent programming languages with support for channels, such as CSP and [Go](https://bliptext.com/articles/go-programming-language).\nThe resulting futures are explicit, as they must be accessed by reading from the channel, rather than only evaluation.","revisionCount":0},"hasMore":false,"nextCursor":null}