[E-Lang] Authority -- what is its dual?
Mark S. Miller
Sat, 20 Oct 2001 12:34:04 -0700
At 10:27 AM 10/19/2001 Friday, Jonathan S. Shapiro wrote:
>>I will offer the following observations that I believe
>> the deep thinkers will agree with:
>> -- Immutable objects do not carry authority.
>I'm afraid this is not correct, and it appears that MarcS is for once badly
>confused. This is rare, but it happens to us all on occasion.
As I mentioned earlier, we're using words differently. I'll answer this
strictly from the E view, and leave open what terms should be used more
generally for security systems or for capability systems. For E, I define
"authority" as those things other than transitive immutables. Again,
perhaps I should find another word (suggestions appreciated), but I want to
get through the current set of messages using one consistent set of
>There are two kinds of things in the world: data and authority.
I think Jonathan means to say "data and capabilities". In any case, I will
proceed to translate him under that assumption. While I would agree with
the translated statement for capability systems in general, in E there is no
"data", as distinct from objects.
>In E, to
>first order, all object references are authorities.
In E, without qualification, all object references are capabilities and all
capabilities are object references.
>In E the definition of capability is a bit more complicated.
In most object systems, and in most capability systems, the only property of
an object reference is which objects it designates. Two object references
that designate the same object are semantically identical.
By contrast, in E's semantics, references are first distinguished by the
reference taxonomy http://www.erights.org/elib/concurrency/refmech.html
and second according to which messages remain undelivered on the reference
http://www.erights.org/elib/concurrency/partial-order.html . This is indeed
more complicated, but seems to successfully lead to an overall simpler and
more robustly programmable system.
>We can approximately take the view
>that a local, intra-vat object reference is a capability with a specially
I don't know about "specially optimized". We're on top of Java, and pay
some further penalties on top of that. In ENative, we hope to have a
specially optimized (fat pointer) representation, but I doubt that's
relevant to the current discussion.
>but if I understand matters correctly, there are
>slight differences in the semantics of intra-vat vs. cross-vat invocations,
As Alan Kay says: "Similar things should be made either the same or very
different." So the differences aren't slight. Cross-vat invocations may
only be eventual, and are vulnerable to partition.
>so if we explore to a sufficient level of detail we may need to conclude
>that E implements two distinct types of capabilities.
Even at lowest resolution, it's three: near, eventual, and broken. See the
reference taxonomy. If you really want to give yourself a scare and see all
the distinctions at once (the high resolution picture), see
>For the moment, you
>can assume that both object references and capabilities in E are
In E, objects reference == capability. "authority" is a different
>An immutable object may contain a capability or an object reference. That
>is, it may contain an authority. Therefore, an immutable object can convey
>authority. Even if it does *not* contain an object reference, an immutable
>object conveys the authority to *read* the data that it contains. Further,
>one must hold authority to the immutable object in order to access its
>contents. Therefore, transferring an immutable object reference constitutes
>a transfer of authority.
None of which applies to our usage.
>> -- The Vector class does not convey authority.
>Nonsense. The vector class, at a minimum, conveys the authority to
>instantiate vector objects. Authority to instantiate objects is a very
>important authority indeed. Further, the vector *instances* convey
>authority: the authority to fetch and store object references
Although it's coincidental, I will point out that I agree that mutable
Vector instances convey authority, but the VectorMaker that makes them
generally does not.
>> There can be, however,
>> classes for which access to the class is an authority even though the
>> class itself is pure computation...
>Ah. This is the heart of MarcS's confusion. Pure computation is not an
>absence of authority. Pure computation, in the sense that I think you mean,
>is only an absence of mutability.
I understand neither MarcS' statement nor your response.