[cap-talk] Wikipedia: Object-capability model - reference vs. capability?

Jonathan S. Shapiro shap at eros-os.com
Wed Jan 17 04:55:34 CST 2007

On Tue, 2007-01-16 at 19:12 -0800, Charles Landau wrote:
> I argue that the number capability in KeyKOS etc. is *not* a 
> reference to an [immutable] data object. If it were, we could use the same 
> hardware "add" instruction to operate on it that we use on ordinary 
> integers.

Um. No.

I understand what you are saying, but when you started talking about
capabilities you moved up at least one layer of abstraction, and then
when you talked about machine instructions you violated the layering.

I agree that a KeyKOS number key is not an immutable data object at the
hardware layer of abstraction. It is a perfectly fine immutable data
object at the capability layer of abstraction.

MarkM's thesis statement:

  "Because data is immutable, we need not distinguish between a
   reference to data and the data itself."

is accurate but incomplete. It is safe to eliminate the distinction
between a reference and its object exactly if the computations invocable
through the reference are "terms" (i.e. pure computation) in the logic
sense. That is: they are a pure and deterministic function of their
arguments. As a matter of implementation, we probably need to require
that the implementation be "memoryless" in the sense of Anita Jones'

This notion of "term" is actually quite consistent. Given a variable v
bound to the result of an expression e1, and a second expression e2, the
rule I am giving is the rule that tells us when it is safe to substitute
e1 for all unbound occurrences of v in e2. Whenever this substitution is
safe, the name 'v' is a pure syntactic convenience, and it is safe to
speak interchangeably of v, its value, and the computation that computed
that value. In a formal sense, all three have identical meaning.

The keykos number key satisfies this test.

> I think we have to choose between two distinct ways to describe the situation.

I propose (3): fixing the definition to replace the discussion of
immutable data objects with a definition that captures the real issue
(some variant of what I said above) and then identify immutable data
objects as an example.

More information about the cap-talk mailing list