Side-effect free containers for E

[Bill Frantz]

At 07:06 PM 8/14/00 -0700, Mark S. Miller wrote:
>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.

I think I am very confused.  As far as I know, KeyKOS/EROS doesn't have
types in a language sense.

Consider the page key.  The base function is read/write.  With that key,
you can get a reduced function, read-only key.  If I were to model this in
the Java type system, I would use Interfaces:

public interface PageRead {
   byte fetch(int offset);
}
public interface PageWrite {
   void store(int offset, byte value);
   PageRead getReadOnly();
}

The classes RWPage and ROPage might look like:

class RWPage implements PageRead, PageWrite {
   ...
   public PageRead getReadOnly {
      return new PageRead(this);
   }
}

class ROPage implements PageRead {
   private RWPage myBase;
   PageRead(RWPage base) {
      myBase = base;
   }
   public byte fetch(int offset, byte value) {
      return myBase.fetch(offset, value);
   }
}

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

Can't I always make a mutable container object by building an object that
uses an immutable container internally, but presents a mutable interface by
always using the most recently produced immutable container to perform a
given function?