Set & Table hierarchy

[Eric Dean Tribble <tribble>]

Abstract: Response to various points by Ravi about how to organize &
   implement the Table and Set hierarchies.

   As Dan Ingalls likes to say: "You can cheat as long as you don't get
   caught.".  I'm thinking in terms of something like the following
   analogies: 

   ImmuTable   :   Orgl
   MuTable     :   Waldo
   Mu (??)     :   Bert or Hand

   Notice that MuTables would *seem* to be wrappers of Bert-like-things
   onto Orgl-like-things, but could have their own protocol identical to
   the current MuTable protocol.  There doesn't actually have to *be* any
   Bert-like-thing or Orgl-like-thing underneath until the client does
   something for which these need to be shown.  I continue to think that
   our plan to have all the implementation classes be the Mu ones is
   good, and does not hinder convergence with an Orgls/Berts/Hands/Waldos
   model.

You, Hugh, and I talked about this a great deal on the phone while I
was in India...

   Even without this, I don't see how to avoid the trick of
   copy-on-write-use with backwards deltas.  Admittedly it is hairy, but
   I don't see how any of the alternatives avoids this hair.  This hair
   seems fundamental to the whole collection system as we've conceived of
   it, independent of whether Immu's are subclasses of Scru's.

I find myself generating tables by accumulating elements.  We might
discover we don't need copy-on-x hair.  For all the stuff I've
generated, the TableAccumulator could have some very straightforward
efficiency hacks and work just fine.  For example, I use an
accumulator to generate and ImmuTable.  It could internally have a
MuTable and a copy-flag.  The copy-flag is true if a storage-sharing
immutable has been handed out (typically only done after all elements
have accumulated).  If there's any possibillity that a returned
ImmuTable might still be around, then it copies the old MuTable and
starts using that.

   Besides, ImmuTable may want to be a subclass of Position.  If
   ImmuTable is a subclass of ScruTable, then ScruTable may want to be
   a subclass of Position, which seems grossly inapproriate.

   Which brings up the question: Should ImmuTable be a subclass of
   Position?  If not, what's the representation of a position in a
   multi-dimensional coordinate space?

No. No. No.  The operations on ImmuTables are unrelated to the
operations on positions.  Instead have a subclass of Position that
represents a position in a multi-dimensional space. The fact that it
uses an ImmuTable for implementation is immaterial.  We've gone around
this before, but not with the current table/region/etc semantics.  Do
we need to?

dean