[E-Lang] Authority -- what is its dual?

Mark S. Miller markm@caplet.com
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
>optimized representation, 

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 
http://www.erights.org/elib/equality/same-ref.html .

>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.