Side-effect free containers for E

[Bill Frantz]

At 05:27 PM 8/16/00 -0400, Jonathan S. Shapiro wrote:
>> >Curiously, KeyKOS and EROS are rife with subtypes that add authority (or,
>> >equivalently, supertypes that subtract authority, ie, "thinning").
>
>> I think I am very confused.  As far as I know, KeyKOS/EROS doesn't have
>> types in a language sense.
>
>Well, yes, it does. We just don't make them terribly explicit.  Also, it's
>not clear that the type relationship has anything to do with sub/supertype.
>
>There is a graph of the rights hierarchy somewhere in my dissertation.
>
>The conversion of R/W foocap to R/O foocap is a pure reduction in strength.
>
>The conversion of a node key to a domain key is a slight reduction in
>strength, as the brand slot becomes inaccessable.
>
>The creation of start/resume keys presents an interesting problem. Since a
>node key cannot do this directly there is a curious question about the type
>lattice that I need to think about at some point.
>
>Weak (sensory) capabilities don't seem to lend themselves to a static type
>characterization at all.

I think your last examples illustrate my point.  Yes, there are types, but
not in a language sense.  Yes, you can get a reference to an object of a
different type which shares implementation with the type you used to get
it.  No, subclassing doesn't describe the type system, and in the case of
node key to domain key, there probably isn't a presentable way of
describing the type change.

I think the right direction for the thinning relationship is to have
language that might look like:

interface NodeKey {
  Key readSlot(int number);
  void writeSlot(int number, key value);
  // etc...
}

interface SenseKey thins Nodekey {
  SensoryKey readSlot(int number);
}

Where SensoryKey is a subset of the values described by Key.  Note that if
a new operation is added to NodeKey, it is not automatically available in
SenseKey (as would be the case with the "extends" interface relationship).