Raphael Collet wrote: > David Hopwood wrote: > >> In some other languages with dataflow variables, they have to be declared. >> For example in E (www.erights.org), "def x" declares a dataflow variable, >> while "var x" declares a mutable variable. The latter is equivalent to a >> variable associated with a first-class mutable "slot" or cell; E's kernel >> language is similar to Oz in that respect. > > There is a slight confusion between dataflow variables and futures here! > A future is the result of a concurrent computation. Dataflow means > that a thread automatically suspends when it needs data that is not > available yet.
Please read my other post for the terminology I'm using. I think it is self-consistent and consistent with the literature. > The language E has futures (called "promises"), but there is no dataflow > at all in E! Thread suspension is simply forbidden in E. You're referring to E's explicit waiting vs Oz's implicit waiting. This is orthogonal to "futures" vs "dataflow variables". Calling E's promises "futures" would not be consistent with how the term "future" has been used in other languages (e.g. MultiLisp and Alice ML). Futures are bound by a specific thread (usually a thread created with the future); E's promises can be bound by any code that has access to the promise's resolver. > When you create a promise in E, you have to explicitly create something > like a "listener", which creates a thread when the promise is resolved, i.e., > the result is known. The when-catch construct doesn't create a thread; it uses the thread associated with the current vat. Also, you use a when-catch whenever you need to ensure that a promise is resolved; it isn't created with the promise. > Dataflow makes all this machinery dynamic and implicit. Implicit waiting may seem more convenient, but it's not compatible with E's event loop concurrency model. The advantages of this model in avoiding deadlock and race conditions are explained in <http://www.erights.org/talks/promises/paper/tgc05.pdf>. Explicit waiting does not lead to any loss of expressiveness. I will grant that E's syntax for explicit waiting is a bit too heavyweight. This can lead to some verbosity in programs that make heavy use of promises. -- David Hopwood <[EMAIL PROTECTED]> _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
