Side-effect free containers for E

[Mark S. Miller]

At 05:53 AM 8/11/00 , Tyler Close wrote:
>You also made the same mistake when you decided to make sets the same
>type as maps. I've found that I often design services where I let
>client code choose which capability to use in performing the service
>by exposing the keys in a (key => cap) map. If I forget to mask off
>the values before passing out the container, I would leak all the
>caps.

I think this is a truly excellent point.  Yes, indeed, this represents a 
second very different instance in which I made the same mistake.  
Congratulations!  I'd say you've internalized the principle of least 
authority better than I.

This is also along the lines of a design rule Dean has advocated (and 
presumably practiced) for Joule code: No subtypes that add authority.  
Echoing Ken's last message, I think this issue is the first showing a 
tension between good capability protocol design practices, and good object 
protocol design practices -- assuming the object designer isn't 
concerned with security per se.  Subtyping, including subtyping that adds 
authority, is part of how object programmers achieve lots of pleasant 
polymorphism without having to say alot.

Of course, for E, the existence of such a tension is especially unfortunate, 
as E is trying to gently seduce object programmers into being capability 
programmers.  E's strategy depends on enabling new E programmers (but old 
object programmers) to build simple things quickly without having to learn 
very much.  So I think E must evaluate separately each case where these 
principles conflict.

Curiously, KeyKOS and EROS are rife with subtypes that add authority (or, 
equivalently, supertypes that subtract authority, ie, "thinning").  Since the 
issue seems to be independent of language vs OS, it will be interesting to 
see how KeyKOS and EROS folks react to this criticism.


For the two cases in front of us, I think Tyler probably wins on both counts.  

* For Sets and Maps, if I made Sets a separate data type, rather than just 
   how the domains of Maps behave, I would not be violating any pre-existing 
   expectation.  I created the extra polymorphism, though, precisely out of 
   those best-practices object principles that we see here is in tension with 
   good capability design principles.

* The danger posed by accidentally leaking mutable containers is too great.  
   The question is:

At 01:52 PM 8/11/00 , Ken Kahn wrote:
>But I wouldn't say they dominated mutable containers in all cases.

Why not?  For what cases do mutable containers dominate?  This is the key 
question.  What if we banish mutable containers from the library documented 
and promoted for normal use?  What do we lose?


         Cheers,
         --MarkM