Andreas Rossberg wrote: > "David Hopwood" <[EMAIL PROTECTED]> wrote: > >>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. > > Futures may or may not be associated with a thread in Alice, as well as in > Oz. Alice has so-called "promised futures", which are also bound through an > explicit "resolver" - the associated promise. Likewise, in Oz you can create > futures from logic variables. They are bound when the associated variable is > bound. In neither case threads are involved.
I should have used just MultiLisp as an example, then; it seems that Alice's terminology is not entirely consistent with earlier usage. CTM, like me, avoids using the term "future" to refer to a read-only view. It is possible to *implement* futures in terms of a dataflow variable, a thread, and a read-only view, as CTM does on page 336. But it is the functionality of the combination that is referred to as a "future" in most of the literature, not the read-only view alone. -- David Hopwood <[EMAIL PROTECTED]> _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
