What’s in a Name?
Several very bright colleagues have proposed in the past that it would be nice if different things had different names and that one merely used its unique name to access the thing.
This indeed seems like the plausible goal of the theory of names.
Such names could be embedded in data carried from one world to another.
Several drawbacks to this plan arise whose resolution bears on capability theory.
Here are some:
- Suppose that machine language represented register names with fields large enough to distinguish not only one register in the CPU from another, but also to distinguish that register from those in other CPUs within the system.
Not only would instructions require more space but processes could no longer migrate freely from one CPU to another as they do now.
Nor could subroutines be shared between processors as each CPU would need a version that addressed its own registers.
It might be argued that register fields within instructions are parameters and not names, but this is a slippery slope (down which I propose to slide!).
Aside from performance, registers seem very much like memory locations.
Engineers know how to build registers so that they are fast to access.
Part of this technique is to give them small names.
The practice of register renaming (a hardware trick invisible to the program) is instructive here but we defer that discussion.
- Suppose that we succeed in building a computing system entirely upon unique names.
We now want to provide a hot standby.
We would normally create the standby by duplicating the state of the first computer bit by bit.
The duplication logic would not need to know which of the bits composed names.
This objection is a thinly disguised version of the preceding one.
- Suppose that we want to debug a deterministic computation by running near variants and tracking their differences.
Requiring the variants to have distinct names for their private parts greatly complicates this technique as the bug we seek may be an illegitimate dependence on a bit in a name.
- Now a programmer may type “CC a.c” to cause a compilation.
What would be necessary in the unique name world?
Perhaps principled exemptions can be found to handle the above cases.
I am skeptical of solutions that propose to use indistinct names with a prescription for pretending that the names are distinct.
On the other hand here is a proposal for unique names.
Capabilities are often described as protected names.
The program holding and wielding a capability is unable to interpret the capability as bits.
The scope of uniqueness of the bits that actually compose a capability is now under control of a program that is in a position to manage the tradeoffs of this scope.
This program is typically outside the application logic.
If I have two computers running capability systems side by side then each is likely to code capabilities to be unique within its own space.
If I buy a new computer with the power to host both systems I will have to recode the representations of capabilities to provide uniqueness across the combined system.
This can be done transparently to the code that defines objects and indeed to all code that is unaware of the number of bits within the capability.
See Password Capability System about a scheme that purports to expose the bits of capabilities and yet provide confinement.
The converse situation arises when we require a system built on capability ideas that must be distributed across several classical capability domains.
We may require the power of more machines than can practically share memory, or perhaps parts of the application must reside at different geographic sites due to bandwidth costs or latency limitations.
CORBA IDL is an approach to this if we recognize capabilities as object references.
Some related notes.
Zooko’s triangle addresses these issues and others.