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

[Mark Miller]

On Tue, Aug 12, 2008 at 8:06 AM, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> On Tue, 2008-08-12 at 16:03 +0100, Ben Laurie wrote:
>> > I'm not sure that
>> > I fully understand what E does here, but I imagine that it may be very
>> > close to the Scheme DELAY and FORCE constructs, with the caveat that
>> > these.


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.

Call-by-value is "strict". Lazy is "non-strict". What this means is that

    def loop() { return loop() }
    def f(a, b) { return a }
    f(1, loop())

in a strict language doesn't terminate, because arguments must finish
evaluating before a call is made. In a non-strict language like
Haskell it returns 1. Since f doesn't use its b parameter, we don't
care that the corresponding argument doesn't terminate.

In E

    f(1, loop <- ())

returns 1. However, it also schedules an infinite turn to occur in the
future, in whatever vat hosts loop. If that's the current vat, then it
will prevent this vat from making further progress once that turn
happens. This blockage is a milder form of strictness. If loop were
instead defined as

    def loop() { return loop <- () }

then we have no strictness blockage.

So, E's eventual-sends and promises are eager -- not lazy -- but non-strict.

> Sorry about the dropped sentence. The rest of that sentence was going to
> read "with the caveat that in some cases the delayed E expressions can
> be evaluated in parallel", but then I realized that I don't know enough
> about the way this works in E to be sure that this is true. In
> particular, if a delayed E form can source or sink mutable values that
> might be subject to modification by the rest of the program, running
> them in parallel would introduce de facto concurrency within a VAT. I
> believe that MarkM took some steps to limit this type of damage, but I
> don't recall what all of them were or whether they were sufficient.

An eventual send queues a pending delivery on the event queue of the
vat hosting the receiver. A vat services its queue in order. Each
event runs to completion before the next begins. There is no
concurrency within a vat.



-- 
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM