[cap-talk] Understanding capabilities in a web-desktop setting

[David-Sarah Hopwood]

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:

<http://en.wikipedia.org/wiki/Futures_and_promises>

# 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
# variable.

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
 > non-strict.

 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.

-- 
David-Sarah Hopwood