Re: [friam] Re: What is a capability?

On Thu, Jan 8, 2015 at 11:08 PM, Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]>
wrote:

> On 1/8/2015 4:53 PM, Kevin Reid wrote:
> > This is what I think of as the difference, and I hope MarkM would agree:
> >
> >
> > A capability system is one which has the laws of locality,
> designation-and-authority-are-not-separated, etc.
> >
> > An object-capability system is a capability system in which the primary
> operation on a capability is "send a message", the message has a
> "selector"/"method name"/"verb" field, and all capabilities are on an equal
> footing in this way. And, more subjectively, the capabilities correspond to
> objects in an object-oriented programming language.
>
> Hmmm.  Perhaps I've been focusing on the wrong thing or over simplifying.
>
> For me the relevant distinction is the membrane pattern.  If a
> capability system supports the membrane pattern (and thus can implement
> services like network capabilities, the Horton responsibility tracking
> mechanism, and other services that depend in this functionally invisible
> "insertion" property) then its "object-capability".  If not, not.
>
> This is why I've encouraged those implementing capability systems to
> test them with a membrane implementation.
>
> I'm not sure how this ability to support the membrane pattern maps into
> the above description.
>
> Can somebody describe the relevant difference and perhaps why the choice
> (definition?) has been made as it is?
>


This is indeed an interesting criteria, but I think it is a different
criteria than ocaps themselves.

In Joule, E, and SES, transparent membranes are possible, not just because
of the ocap properties, but because all first class values are either
* data -- immutable and transparent (though not necessarily identity-free)
* objects -- whose only observable properties are their identity and their
response to messages.

By contrast:

In W7 (an ocap subset of scheme) transparent membranes are not possible,
because cons cells are mutable and one cannot transparently intermediate
(or virtualize) a cons cell. For APIs consisting only of data and
functions, membranes are possible. (Racket, a successor to Scheme, makes
transparent membranes possible. But there is not yet an ocap subset of
Racket, so it is outside this taxonomy.)

In Joe-E (an ocap subset of Java), transparent membranes are not possible,
because one cannot transparently intermediate final classes or classes with
final members. For APIs consisting only of data and interface types,
membranes are possible.

In Emily (an ocap subset of OCaml), transparent membranes are not possible,
because all types are static without the ability to operate on them
generically. OTOH, I posed this as a challenge at <
http://lambda-the-ultimate.org/node/1625#comment-19906>. The thread
starting there ultimately claims to have arrived at a solution, but it was
one I could not comprehend.

KeyKOS is where I got the idea of membranes (from their KeySAFE design,
although your DCCS preceded it my many years). Thus, it would be strange to
claim that membranes are not possible in the KeyKOS family. But Kevin's
point about pages leaves me wondering if transparent membranes are
possible. I know you can use a Keeper to trap on attempt to access an
unmapped page, and that the keeper can act in such a way as to emulate a
page having been there all along. I.e., Keepers allow you to play
fault-handling tricks like virtual memory with user code. But not by
intercepting the memory access as a message invoked on a start key. In what
way can a Keeper provide virtualized access to another memory page without
providing direct access to that page?

So, I think there are three levels of increasing specificity:

a) ocap
b) ocap where limited non-transparent membranes are possible
c) ocap where transparent membranes are possible.

Joule, E, and SES are in #c. IIUC, so are Actors.

Jed, is it correct to say that DCCS is in #c as well? How did you handle
mapping and virtualization of addressable memory resources?

-- 
    Cheers,
    --MarkM

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk