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

[David Hopwood]

Charles Landau wrote:
> A data object is immutable data, such as the integer 7. There's only 
> one seven, but there can be many references to it. A reference to the 
> integer 7 is often represented by the bits "111" in a data register. 
> CPU manufacturers provide operations such as "add" that take 
> references to two integers, dereference them, add the numbers, and 
> output a reference to the resulting number. This is fortunate for us 
> object-capability mavens, because there is no way to dereference 
> these references and get our hands on the actual numbers.
> 
> Most people think of this as operating on the numbers themselves, not 
> on references. But I'm happy with the reference terminology as long 
> as we all understand it.
> 
> As MarkM points out [thesis p.65]: "Because data is immutable, we 
> need not distinguish between a reference to data and the data 
> itself." But for this discussion, please let's be clear which we are 
> talking about.
> 
> A reference (i.e. a pointer) to an integer *variable* is *not* a 
> reference to a data object. An integer variable contains a 
> *reference* to an integer, and may contain different references at 
> different times.
> 
>>I don't find these other types of references confusing (perhaps because
>>I have a programming language background, and the use of "reference"
>>here exactly corresponds to the OO language usage).
> 
> I'm surprised by this, but I'll defer to the language folks. Are 
> there languages other than Algol68

Algol68 terminology uses the term "reference" to mean a cell, although
Algol68's semantics an be considered as you describe above.

> that use references to integers this way?

Yes, plenty: Smalltalk, the ML family, all Lisps, E, Haskell, etc.
Once you are used to such languages, you tend to view the semantics
of all languages in a similar way, even if the mapping is sometimes a
little forced.

> I argue that the number capability in KeyKOS etc. is *not* a 
> reference to a data object. If it were, we could use the same 
> hardware "add" instruction to operate on it that we use on ordinary 
> integers.

I think this is focussing too much on an implementation detail. In general,
it may or may not be the case that the representation of a reference to a small
integer is compatible with the hardware "add" instruction (it may have tag bits,
or not, and sometimes the tag bits are chosen in order to make use of hardware
"add" possible except in case of overflow). Why does this matter?

> Instead, it is a reference to an immutable object that responds to certain
> invocations by returning its data.

Again, this is an implementation detail, not important to the mapping of
KeyKOS to the object-capability model.

> Clearly the number capability containing the number 7 is different from a 
> reference to the data object 7. Thus the number capability is truly a
> capability and can be held in a capability register.
> 
> Unfortunately the definition of data object in the
> [[object-capability model]] Wikipedia article fails to make this clear.
>
> I think we have to choose between two distinct ways to describe the situation.
> 
> 1. The "MarkM thesis" description. The distinction is between 
> references to data objects, and references to non-data objects (the 
> latter being capabilities). The article currently mostly conforms to 
> this, but the definition of data object needs to be fixed.

The current definition is "An object that provides only unconditional access
to immutable information." What is wrong with this? The object "7", for example,
conforms to this definition.

> Also, instead of saying references *can* be embedded in messages, it is 
> really the case that messages contain *only* references.

You can consider it that way, but I didn't want to give the impression that
messages have to be first-class.

> The article also says references are unforgeable. I hope I can forge 
> a reference to any integer I like. Should it say only that 
> capabilities are unforgeable?

While it's technically more correct to say "references, which are unforgeable
if they point to non-data", this would make the introduction quite verbose
and dependent on a distinction that is only explained later.

I tend to just think "unforgeable references", and define away the issue by
saying that constructing an integer (or other data) reference is not forgery.
Alternatively, it's sufficient to consider all processes as starting with
references to the integers that are mentioned as literals in their source code,
and references to function objects that implement the primitive operations on
integers.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>