Pre-postlude: I wrote the following when I could not understand why some thought that CPS was not the entire answer. Subsequently I talked with Chip who gave me an iron-clad reason. It takes a few minutes to sort of understand continuations but at least a day’s hard work to convince yourself that continuations are indeed a valid replacement for the call-return paradigm. Chip needs to explain capability propagation rules to those unfamiliar with CPS.

Regarding Chip Morningstar’s observations on the Granovetter Diagram and the common pattern of X calling Y in order to get from Y, a capability to Z. Chip observes that the initial conditions seem not to match the initial Granovetter pattern, nor any other of the commonly accepted patterns of how capabilities get around.

Prepositions: If is B is a capability to interact with b then in this note we say that “B is a capability for b.”. This avoids the confusing constructs such as “I send a capability to P to Q.”.

Adopting CPS (Continuation Passing Style), as Chip suggests, here is how I tell the story so as to conform to Granovetter’s insight:

  1. X holds a capability for calling Y who holds a capability for Z.
  2. X sends to Y a message: The message includes a continuation to X.
  3. Y receives the message and part of Y’s charter is to hold a few capabilities and hand them to whoever has the authority to send messages to Y. Selection among those few is made according to details that do not concern us here.
  4. Y sends a message which includes the cap for Z to X via the continuation with the text:
  5. Upon receipt, X holds a capability for Zelda.
I claim that steps 4 and 5 perfectly match the Granovetter Diagram. X’s first action is to bring forth the situation where the Granovetter introduction can occur. In step 3 there is some fog about how Y comes to hold the continuation, which is assuredly a capability. You can’t quite say that X held it before the sending event. You can say that X performed an atomic operation which did these inseparable actions all at once:

Looking Closer

In Keykos Y is most likely a node (capability page) and the code defining its behavior is in the kernel and the call-return events are all one atomic operation; the continuation never actually exists. Generally X is not in a position to know that Y is a node however, merely that it behaves enough like a node.