[cap-talk] Understanding capabilities in a web-desktop setting
david.hopwood at industrial-designers.co.uk
Wed Aug 13 15:44:51 CDT 2008
Tony Finch wrote:
> On Tue, 12 Aug 2008, Jonathan S. Shapiro wrote:
>> You explain how things should *not* be described, but you have not
>> clarified for Ben how they *should* be described.
>> Can you do so? He needs a term, not a paragraph.
> I have heard promises described as data-flow variables.
The meaning of "dataflow variable" is a little more specific:
# A concurrent logic variable is similar to a promise, but is updated
# by unification, in the same way as logic variables in logic programming.
# Thus it can be fulfilled more than once with unifiable values. In the Oz
# programming language, a concurrent logic variable is called a dataflow
I haven't heard "dataflow variable" used outside the context of
concurrent logic programming (or systems inspired by Oz, even
if those are not strictly logic programming systems).
Mark Miller wrote:
> Scheme DELAY & FORCE, the typical use of terms such as "delayed
> evaluation" and "call by need" all refer to "lazy evaluation"
> mechanisms. Haskell is lazy by default. Scheme is call-by-value by
> default, but DELAY and FORCE are patterns for building lazy from this.
> E's eventual-sends and promises are *not* lazy evaluation mechanisms.
> They can be described by the term "delayed evaluation" I suppose, but
> shouldn't be since people will assume this means lazy.
> So, E's eventual-sends and promises are eager -- not lazy -- but
From the same Wikipedia page as above:
# To implement implicit lazy futures in terms of promises requires a
# mechanism to determine when the promise's value is first needed (for
# example the WaitNeeded construct in Oz). The ability to implement
# transparent forwarding objects (as supported by E and Joule) is
# sufficient, since the first message sent to the forwarder indicates
# that the promise is needed.
More information about the cap-talk