Future与promise (Chinese Wikipedia)

Analysis of information sources in references of the Wikipedia article "Future与promise" in Chinese language version.

refsWebsite
Global rank Chinese rank
1st place
1st place
383rd place
336th place
2,232nd place
1,779th place
low place
low place
1,185th place
809th place
1,686th place
1,446th place
low place
low place
low place
low place
153rd place
238th place
2nd place
23rd place
1,514th place
1,383rd place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
11th place
332nd place
low place
low place
low place
low place
230th place
439th place
low place
low place
415th place
500th place
low place
5,245th place
low place
low place
low place
low place
120th place
337th place
low place
low place
207th place
628th place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
8,973rd place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
low place
24th place
29th place
low place
low place
low place
low place
low place
low place
4,903rd place
7,274th place
910th place
767th place
low place
low place
7,871st place
6,207th place
low place
low place
low place
low place
low place
low place
low place
low place
67th place
154th place
1,669th place
1,456th place
low place
low place
1,518th place
1,980th place
low place
low place
low place
low place
low place
low place
low place
low place
5,959th place
1,172nd place

acm.org

dl.acm.org

  • Henry Baker; Carl Hewitt. The Incremental Garbage Collection of Processes. Proceedings of the Symposium on Artificial Intelligence Programming Languages,. ACM Sigplan Notices 12, 8: 55–59. August 1977 [2024-01-26]. (原始内容存档于2024-04-12). In this paper we consider an "eager beaver" evaluator for an applicative programming language which starts evaluating every subexpression as soon as possible, and in parallel. This is done through the mechanism of futures, which are roughly Algol-60 "thunks" which have their own evaluator process ("thinks"?). (Friedman and Wise [10] call futures "promises", while Hibbard [13] calls them "eventuals".) When an expression is given to the evaluator by the user, a future for that expression is returned which is a promise to deliver the value of that expression at some later time, if the expression has a value. A process is created for each new future which immediately starts to work evaluating the given expression. ……
    The intuitive semantics associated with a future is that it runs asynchronously with its parent's evaluation. This effect can be achieved by either assigning a different processor to each future, or by multiplexing all of the futures on a few processors. Given one such implementation, the language can easily be extended with a construct having the following form: "(EITHER <e1> <e2> … <en>)" means evaluate the expressions <ei> in parallel and return the value of "the first one that finishes".
     
  • Barbara Liskov; Liuba Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation; Atlanta, Georgia, United States. ACM: 260–267. 1988 [2024-01-26]. ISBN 0-89791-269-1. doi:10.1145/53990.54016. (原始内容存档于2024-01-26). Promises were designed to support an efficient asynchronous remote procedure call mechanism for use by components of a distributed program. A promise is a place holder for a value that will exist in the future. It is created at the time a call is made. The call computes the value of the promise, running in parallel with the program that made the call. When it completes, its results are stored in the promise and can then be “claimed” by the caller. ……
    Call-streams allow a sender to make a sequence of calls to a receiver without waiting for replies. The stream guarantees that the calls will be delivered to the receiver in the order they were made and that the replies from the receiver will be delivered to the sender in call order. ……
    The design of promises was influenced by the future mechanism of MultiLisp[5]. Like futures, promises allow the result of a call to be picked up later. However, promises extend futures in several ways: Promises are strongly typed and thus avoid the need for runtime checking to distinguish them from ordinary values. They allow exceptions from the called procedure to be propagated in a convenient manner. Finally, they are integrated with the call-stream mechanism and address problems such as node failures and network partitions that do not arise in a single-machine environment. ……
    There are two reasons for using stream calls instead of RPCs: they allow the caller to run in parallel with the sending and processing of the call, and they reduce the cost of transmitting the call and reply messages. RPCs and their replies are sent over the network immediately, to minimize the delay for a call. Stream calls and their replies, however, are buffered and sent when convenient; in the case of sends, normal replies can be omitted. Buffering allows us to amortize the overhead of kernel calls and the transmission delays for messages over several calls, especially for small calls and replies.
      Also published in ACM SIGPLAN Notices 23(7).
  • Domenico Talia. Survey and comparison of PARLOG and Concurrent Prolog. 1990 [2024-03-13]. (原始内容存档于2024-03-13). Concurrent logic languages are born from a new interpretation of Horn clauses, the process interpretation. According to this interpretation, an atomic goal ← C can be viewed as a process, a conjunctive goal ← C1, …, Cn, as a process network, and a logic variable shared between two clauses can be viewed as a communication channel between two processes. 

angularjs.org

aosabook.org

apple.com

developer.apple.com

appliedgo.net

archive-it.org

wayback.archive-it.org

  • Lazy. caml.inria.fr. [2018-12-31]. (原始内容存档于2015-07-06). 

bitbucket.org

boost.org

c2.com

celluloid.io

codehaus.org

gpars.codehaus.org

common-lisp.net

commonjs.org

wiki.commonjs.org

cujojs.com

dartlang.org

dartlang.org

api.dartlang.org

dist-prog-book.com

doi.org

  • Halstead, Robert H. Jr. MultiLisp: A Language for Concurrent Symbolic Computation. ACM Transactions on Programming Languages and Systems. October 1985, 7 (4): 501–538. S2CID 1285424. doi:10.1145/4472.4478可免费查阅. Multilisp's principal construct for both creating tasks and synchronizing among them is the future. The construct (future X) immediately returns a future for the value of the expression X and concurrently begins evaluating X. When the evaluation of X yields a value, that value replaces the future. The future is said to be initially undetermined; it becomes determined when its value has been computed. An operation (such as addition) that needs to know the value of an undetermined future will be suspended until the future becomes determined, but many operations, such as assignment and parameter passing, do not need to know anything about the values of their operands and may be performed quite comfortably on undetermined futures. ……
    The future construct in Multilisp, for example, offers a way to introduce parallelism that fits very nicely with the principal program operation of Multilisp — expression evaluation. Also, no special care is required to use a value generated by future. Synchronization between the producer and the users of a future’s value is implicit, freeing the programmer’s mind from a possible source of concern.
     
  • Barbara Liskov; Liuba Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation; Atlanta, Georgia, United States. ACM: 260–267. 1988 [2024-01-26]. ISBN 0-89791-269-1. doi:10.1145/53990.54016. (原始内容存档于2024-01-26). Promises were designed to support an efficient asynchronous remote procedure call mechanism for use by components of a distributed program. A promise is a place holder for a value that will exist in the future. It is created at the time a call is made. The call computes the value of the promise, running in parallel with the program that made the call. When it completes, its results are stored in the promise and can then be “claimed” by the caller. ……
    Call-streams allow a sender to make a sequence of calls to a receiver without waiting for replies. The stream guarantees that the calls will be delivered to the receiver in the order they were made and that the replies from the receiver will be delivered to the sender in call order. ……
    The design of promises was influenced by the future mechanism of MultiLisp[5]. Like futures, promises allow the result of a call to be picked up later. However, promises extend futures in several ways: Promises are strongly typed and thus avoid the need for runtime checking to distinguish them from ordinary values. They allow exceptions from the called procedure to be propagated in a convenient manner. Finally, they are integrated with the call-stream mechanism and address problems such as node failures and network partitions that do not arise in a single-machine environment. ……
    There are two reasons for using stream calls instead of RPCs: they allow the caller to run in parallel with the sending and processing of the call, and they reduce the cost of transmitting the call and reply messages. RPCs and their replies are sent over the network immediately, to minimize the delay for a call. Stream calls and their replies, however, are buffered and sent when convenient; in the case of sends, normal replies can be omitted. Buffering allows us to amortize the overhead of kernel calls and the transmission delays for messages over several calls, especially for small calls and replies.
      Also published in ACM SIGPLAN Notices 23(7).

dojotoolkit.org

elm-lang.org

package.elm-lang.org

  • Task. [2018-12-31]. (原始内容存档于2018-12-31). 

erights.org

erights.org

wiki.erights.org

  • Promise, E rights, [2018-12-31], (原始内容存档于2018-12-31) 

geeksforgeeks.org

github.com

groups.google.com

haskell.org

downloads.haskell.org

haskell.org

ieeeghn.org

inria.fr

caml.inria.fr

  • Lazy. caml.inria.fr. [2018-12-31]. (原始内容存档于2015-07-06). 

iolanguage.org

jdeferred.org

  • JDeferred. JDeferred. [2019-01-04]. (原始内容存档于2019-01-08). 

jquery.com

jquery.com

api.jquery.com

kotlinlang.org

lparallel.org并行Lisp

marijnhaverbeke.nl

  • PCall. marijnhaverbeke.nl. [2018-12-31]. (原始内容存档于2020-08-06). 

metacpan.org

microsoft.com

devblogs.microsoft.com

msdn.microsoft.com

learn.microsoft.com

mikeash.com

mit.edu

pmg.csail.mit.edu

  • Argus, MIT, [2018-12-31], (原始内容存档于2018-04-27) 

mochi.github.io

mozart-oz.org

mozilla.org

developer.mozilla.org

nodejs.org

oracle.com

docs.oracle.com

orthecreedence.github.io

pocoproject.org

promisesaplus.com

psu.edu

citeseerx.ist.psu.edu

  • Kenjiro Taura; Satoshi Matsuoka; Akinori Yonezawa. ABCL/f: A Future-Based Polymorphic Typed Concurrent Object-Oriented Language – Its Design and Implementation.. In Proceedings of the DIMACS workshop on Specification of Parallel Algorithms, number 18 in Dimacs Series in Discrete Mathematics and Theoretical Computer Science. American Mathematical Society: 275–292. 1994. CiteSeerX 10.1.1.23.1161可免费查阅. 

python.org

python.org

  • PEP 0492 – Coroutines with async and await syntax. [2018-12-31]. (原始内容存档于2019-01-05). 
  • Python 3.2 发布. Python.org. [2018-12-31]. (原始内容存档于2018-12-31). 
  • PEP 3148 – futures - execute computations asynchronously. [2018-12-31]. (原始内容存档于2018-12-31). The proposed design of this module was heavily influenced by the Java java.util.concurrent package [1]. The conceptual basis of the module, as in Java, is the Future class, which represents the progress and result of an asynchronous computation. The Future class makes little commitment to the evaluation mode being used e.g. it can be used to represent lazy or eager evaluation, for evaluation using threads, processes or remote procedure call.
    Futures are created by concrete implementations of the Executor class (called ExecutorService in Java). The reference implementation provides classes that use either a process or a thread pool to eagerly evaluate computations.
     
  • Python 3.5.0 发布. Python.org. [2018-12-31]. (原始内容存档于2019-01-05). 

docs.python.org

qt-project.org

r-project.org

cran.r-project.org

racket-lang.org

docs.racket-lang.org

raku.org

docs.raku.org

researchgate.net

  • Don Syme; Tomas Petricek; Dmitry Lomov. The F# Asynchronous Programming Model, PADL 2011. 2010-10-21. This paper describes the asynchronous support in F# 2.0. While the core idea was released and published in book form 2007, the model has not been described in the conference literature. 

rubygems.org

rust-lang.org

doc.rust-lang.org

scala-lang.org

docs.scala-lang.org

seastar-project.org

  • Seastar. Seastar project. [2016-08-22]. (原始内容存档于2016-08-20). 

semanticscholar.org

api.semanticscholar.org

  • Halstead, Robert H. Jr. MultiLisp: A Language for Concurrent Symbolic Computation. ACM Transactions on Programming Languages and Systems. October 1985, 7 (4): 501–538. S2CID 1285424. doi:10.1145/4472.4478可免费查阅. Multilisp's principal construct for both creating tasks and synchronizing among them is the future. The construct (future X) immediately returns a future for the value of the expression X and concurrently begins evaluating X. When the evaluation of X yields a value, that value replaces the future. The future is said to be initially undetermined; it becomes determined when its value has been computed. An operation (such as addition) that needs to know the value of an undetermined future will be suspended until the future becomes determined, but many operations, such as assignment and parameter passing, do not need to know anything about the values of their operands and may be performed quite comfortably on undetermined futures. ……
    The future construct in Multilisp, for example, offers a way to introduce parallelism that fits very nicely with the principal program operation of Multilisp — expression evaluation. Also, no special care is required to use a value generated by future. Synchronization between the producer and the users of a future’s value is implicit, freeing the programmer’s mind from a possible source of concern.
     

sitepen.com

sourceforge.net

sunless-sea.net

sylvain-huet.com

  • Rishiyur S. Nikhil. ID Reference Manual (PDF). 1991 [2024-03-13]. (原始内容存档 (PDF)于2024-05-19). A component of a data structure may have I-structure semantics (as opposed to functional or M-structure semantics). For such a component, no value is specified when the data structure is created; instead, a separate assignment statement is used. An I-structure component may be in one of two states: be full (with a value), or empty. all components begin in the empty state (when the data structure is allocated).
    An I-structure component has a single assignment restriction, i.e. it can only be assigned once, at which point its state goes from empty to full. Any attempt to assign it more than once is caught as a runtime error. The component can be read an arbitrary number of times.
    ……
    An M-structure component can be assigned with a put operation and read with a take operation. A value can be put only into an empty component — it is a runtime error if it is already full. Many take's may be attempted concurrently on a component.
     

threads.js.org

tomasp.net

  • Tomas Petricek. Asynchronous C# and F# (I.): Simultaneous introduction. 2010-10-29 [2018-12-31]. (原始内容存档于2018-12-31). Currently, you can run the operation on a background thread or using a Task, but coordinating multiple such operations is difficult. …… This problem has been the main motivation for including asynchronous workflows in F# about 3 years ago. In F#, this also enabled various interesting programming styles - for example creating GUI using asynchronous workflows ……. The C# asynchronous programming support and the await keyword is largely inspired by F# asynchronous workflows ……. 

twisted.org

docs.twisted.org

twitter.github.io

  • Util. twitter.github.io. [2018-12-31]. (原始内容存档于2018-12-23). 

uchicago.edu

cml.cs.uchicago.edu

  • The Concurrent ML Reference Manual — The SyncVar structure. [2024-03-13]. (原始内容存档于2024-05-10). The SyncVar structure provides Id-style synchronous variables (or memory cells). These variables have two states: empty and full. An attempt to read a value from an empty variable blocks the calling thread until there is a value available. An attempt to put a value into a variable that is full results in the Put exception being raised. There are two kinds of synchronous variables: I-variables are write-once, while M-variables are mutable. 

udanax.com

uni-saarland.de

ps.uni-saarland.de

  • Gert Smolka. Concurrent Constraint Programming Based on Functional Programming. 1998 [2024-03-13]. (原始内容存档于2024-03-13). As base language we choose a dynamically type language DML that is obtained from SML by eliminating type declarations and static type checking. ……
    A state is a finite function σ mapping addresses a to so-called units u. Units are either primitive values other than names or representations of records, variants, reference cells, functions, and primitive operations …… A match Match is a sequence of clauses (p1 ⇒ e1 | … | pk ⇒ ek). ……
    We now extend DML with logic variables, one of the essentials of logic programming. Logic variables are a means to represent in a state partial information about the values of addresses. Logic variables are modelled with a new unit lvar. The definition of states is extended so that a state may map an address also to lvar or an address. ……
    A match …… blocks until the store contains enough information to commit to one of the clauses or to know that none applies.
     
  • Jan Schwinghammer. A Concurrent Lambda Calculus with Promises and Futures. 2002 [2024-03-14]. (原始内容存档于2024-03-14). General logic variables stem from the class of logic programming languages such as Prolog [Pro85, SS94, JL87]. Initially, when freshly introduced, they carry no value. Therefore they allow for the stepwise construction of values, using further logic variables for the construction of subvalues if necessary. They are transient, in that they are identified with their value as soon as this becomes available. This provides a mechanism for implicit synchronization of concurrent threads that share a logic variable: A thread reading the variable automatically suspends while sufficient information is not available.
    We will be concerned with futures and promises, which differ from general logic variables in that a distinction is made between reading and writing them. Bidirectional unification can be replaced by (single-) assignment.
     
  • Alice manual — Future. [2024-03-13]. (原始内容存档于2024-04-17). 
  • Alice Manual — Promise. [2024-03-13]. (原始内容存档于2024-04-17). 

web.archive.org

webcitation.org