At 04:53 PM 10/26/99 , Mark S. Miller wrote:
>* "stable", auditing that
> all instance variables are final(stable)
> or final(someType) where someType is on a small static list of types
> known to be transitively immutable
> or final and initialized to a literal transitively immutable object
>"stable" is really "transitively immutable", which is to say, transitively non-authority granting. Everything defined at top-level in a *.emaker file must be stable, so that *.emaker files can import: each other by name with no capability controls. This is the E analog of the Original-E rule that E-safe Java classes could not have native methods, could only import classes known to be E-safe, and that all their static state had to be transitively immutable. Rees's recent paper about Scheme security imposes a logically identical constraint. For syntactic convenience, as top level, all undeclared variable definitions are provided with the definition ": (final(stable))", and all top-level behavior definitions are provided with the auditor ":: stable".
Another interesting thing about stable (ie, transitively immutable) objects: They can be safely shared by multiple vats in the same address space. An intra-jvm inter-vat comm system connection can stop serializing when it hits an object that is both stable and PassByCopy. Instead, it can merely pass a pointer.