Welcome back, Jonathan!
> My apologies for getting into this thread so late. The SOSP deadline has been
> driving me very hard.
>
> I have two thoughts to add. Perhaps they may not be helpful.
>
> First, after a while working on formal stuff around capabilities, I have come
to
> the feeling that describing capabilities as a
>
> (name, access rights)
>
> or
>
> (name, operation)
>
> pair is not the best description. I have not yet found good words to describe
> what I want, but here is a description.
>
> A capability is a pair of the form
>
> (name to thing of type X, some thinning of the signature of type X)
I was going to follow up on the conversation with my intuition--which obviously is not nearly as well-crafted as yours--that a "capability" maps fairly nicely to either the "Proxy" or "Facade" pattern(s) from the Gang of Four, which I think is reflected nicely in the "(name to thing of type X, some thinning of the signature of type X)" idea. I also wanted to raise the question as to what this intuition means to notions of comparison, identity, equality, and so on--issues that I know the E team has grappled with extensively.
> Alternatively, if you wish to consider it in lambda calculus terms, it is the
> result of evaluating
>
> (apply (lambda object (lambda method (lambda args ((apply method x)
> args)))) some-object)
>
> To really get that right I would need typed lambda calculus, but I hope the
idea
> is clear. A capability is a signature closed over some object. Therefore, the
> answer to the discussion about lambdas being anonymous capabilities is yes and
> no:
Typed lambda calculus... would there be some better way to express these concepts in, e.g. Standard ML than in Scheme? Is there possibly some connection to Joe Kiniry's work on "Kinds" at Caltech? (see <http://www.cs.caltech.edu/~kiniry/projects>).
>>> I guess in a distributed scheme, you could look at every lambda as an
>>> anonymous capability?
>>
>>Assuming that the lambda expression somehow expressed access rights as well
>>as functionality, yes.
>
> All lambda expressions capture access rights, in the sense that they close
over
> a set of operations performed by their bodies. The notion of "anonymous
> capability" doesn't work, though. You need a lambda expression that has bound
> its first argument (the object).
Quite right. You beat me to clarifying that when I said "object reference plus access rights," I meant "object reference plus collection of interfaces that represent a subset of the total collection of interfaces to the object referred to." Among the implications I wanted to make clear (or, more accurately, request clarification on in the event my intuitions are poor) was that two capabilities might carry the same object reference but totally different collections of interfaces presented by that object. In such a case, would the two capabilities be considered "identical?" "Equal?"
> My second thought concerns the statement:
>
>> if you have a capability, you have it, and that's that.
>
> This is accurate, but sometimes misleading, because it suggests that you
> actually have access to the object that the capability names. In some sense
you
> do, but in the face of simulating front ends you may not. It is *sometimes*
> better to think about this as:
>
>> if you have a capability, you have what it ALLEGES, and that's that.
Yes, I believe the latter is always (ideally) the case. Again, I liken a capability to a Proxy or Facade pattern, where I do not have access to the object(s) encapsulated by the Proxy or Facade.
> Jonathan S. Shapiro, Ph. D.
> IBM T.J. Watson Research Center
> Email: shapj@us.ibm.com
> Phone: +1 914 784 7085 (Tieline: 863)
> Fax: +1 914 784 7595
>
>
>
Thanks for bringing some clarity to my off-the-cuff ramblings! Paul
-- Please reply to <mailto:psnively@earthlink.net> using PGP. My public key can be found at <http://pgpkeys.mit.edu:11371>. PGP can be found at <http://web.mit.edu/network/pgp.html>. Beginning 11/1/1999, unenciphered e-mail will be immediately deleted unread. Thank you.