RE: Capabilities and RPC calls... Mark S. Miller (markm@caplet.com)
Mon, 18 Oct 1999 12:50:40 -0700

MarkM wrote:
> > (define (sillyPair x y)
> > (cons (lambda () (+ x y)) (lambda () (* x y))))
> >
> > This returns a cons of two functions defined in the same
> > scope and therefore encapsulating the same state. They
> > both have same type signature: no arguments -> number.
> > However, they each pair a different behavior to be
> > executed over this state. ...

At 07:32 AM 10/17/99 , Gavin Thomas Nicol wrote:
>So capababilities are more like continuations?

I am totally confused by this comment. If you meant "closures", then yes, that's exactly what I was trying to explain. In a secure lambda language, including, in historical sequence, the original Actors languages, Trusty Scheme (unpublished), Joule, Rees' W7/Scheme48, and E, closures *are* capabilities.

>I'm starting to
>get a distinct feeling that either a number of areas talk about
>the same thing in different terms, or that a number of different
>areas are converging.

They started out converged, as Hewitt's original writings about Actors shows that he independently rediscovered the capability concept as part of the same seminal work in which he introduced lexical closures to a computer science that thought it knew about lambda abstraction. Unfortunately, that connection seems to have been immediately forgotten by Hewitt in his later writings, and by Sussman & Steele when, inspired by Actors, they created Scheme.

Although Scheme was not designed to be capability secure, it nevertheless retained the security that should come from a consistent principled application of lambda calculus. This fact was not publicly discovered until Rees' 1995 thesis.

For a good short introduction to these issues, I once again refer you to our paper, http://www.erights.org/elib/capability/ode/ , and particularly the first two sections: "From Functions to Objects" and "From Objects to Capabilities". The references contains pointers to many of the systems I refer to above.

For an old explanation of the capability nature of Actors and Flat Concurrent Prolog, see "Language Design and Open Systems" by Ken Kahn & myself, published in The Ecology of Computation, 1988.

At 07:13 AM 10/17/99 , Gavin Thomas Nicol wrote:
> > (name to thing of type X, some thinning of the signature
> > of type X)
>....
> > if you have a capability, you have what it ALLEGES, and that's that.
>
>Both of these seem to stem from the desire to avoid confusion over
>name vs. identity. Correct?

No. Jonathan made an unfortunate expository choice in using the term "name" above. Please replace with "pointer to thing of type X" or "designates thing of type X". Also, pending resolution of what ML means by "type" (an unanswered question from a previous message), I continue to maintain that a capability doesn't thin a type signature, it thins (or subsets) the behaviors of the thing accessible over the capability. In fact, I think we are only asking for confusion by bring in the notion of type at this level. Therefore, I would replace the above with

(designates a thing, access to a subset of the behaviors of that thing)

ie, a pair of state and behavior, as explained in our paper.

> >(apply (lambda object (lambda method (lambda args ((apply method x)
> > args)))) some-object)
>
>This makes it perfectly clear.

Not to me. What does this code say to you? 

         Cheers,
         --MarkM