Set & Table hierarchy

[Mark S. Miller <mark>]

Date: Mon, 20 Nov 89 00:13:02 PST
   From: tribble (Eric Dean Tribble)

      ...

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

True.  I try to be good about attribution, but slip occasionally. 

      ...

   I find myself generating tables by accumulating elements.  We might
   discover we don't need copy-on-x hair.  ... 
   If there's any possibillity that a returned
   ImmuTable might still be around, then it copies the old MuTable and
   starts using that.

Yes, if you know you are in this special situation and know that
actually copying when you may not need to is something you can afford,
and you use implementations which are suitable for this special
situation... 

What I meant was I didn't see how to avoid this copy-on-write-use hair
and not *copy when we didn't actually need to*, and support any of the
proposed Table protocols.  Note that we *don't* have to have an
implementation that provides such a strong guarantee; but the lack of
such a guarantee is affordable given many more assumptions about the
needs of our code (assumptions like the above).  That is why anything
significantly more sophisticated that an "actually naively copy"
strategy should wait till performance engineering phase.  Then we will
know much more about what cases we actually need.

      ...

   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?

I'm afraid we do.  I am rather leaning towards your side of the
argument (sorry, too confrontaional, make that "discussion" :->),
which would seem to suggest a new class called ImmuTableAsPosition.

In which case this argument against having ImmuTable be a subclass of
ScruTable would go away.  I now also believe less in the other
argument too.  However, I still like having the Table stuff converge
with the Orgl/Bert/... stuff.  This may mean that Orgls & some kind of
Waldo (that represents a "modifiable orgl" sort of) may have a common
Orgl-like superclass.  Wierd, but probably correct.  (Or, as Bohr may
have asked: "is this wierd enough to be correct?".)

As a development strategy (which we can get away with since we're
hiding Orgls), let's merge the Table hierarchy, but keep Orgls and
Waldos separated for now.  But let's keep this in mind.