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

[Jonathan S. Shapiro]

Mark:

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.

shap


On Tue, 2008-08-12 at 09:37 -0700, Mark Miller wrote:
> 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.
> 
> 
>