sneaky uses for copy-on-write

[Eric Dean Tribble <tribble>]

Note that this requires reference counting for Tables.  It is
      efficient only if the 'ocrums' set gets immediately deallocated when
      NULL is assigned.  We can't make an explicit delete because ocrums
      might be shared.

   I'm worried about the number and kinds of cases that our garbage
   collector is going to be expected to handle.  You are correct that
   copy-on-write for Tables only works well when unreferenced Tables get
   *immediately* finalized.  RefCounts can do this, and the alternatives
   that I know of cannot.  However, because of potential cycles,
   refCounts cannot handle everything, neither are they (probably) as
   efficient as the non-immediate alternatives.  One possibility that
   we've talked about is to refCount collect types that may appear in
   cycles, and collect other types using a non-immediate alternative.
   Note that, though Tables typically will not appear in cycles, they
   *may*, and therefore are yet a third, mixed, case.  Yucko!

It's not quite so bad (note that this is speculation based on NOT
being the garbage collector implementor).  We need two roughly
orthogonal mechanisms.  The garbage collector walks over most classes
of objects and finalizes then when it finds circularities.
RefCounting finalizes objects when the number of references goes to 0.
Both mechanism need to operate properly in the face of external
finalization because programmers might add their own deletes.  To a
referenced counted pointer, the garbage collector looks like a
scrupulous programmer.  And vice-versa.  Completely separate from all
this are objects that don't need to be garbage collected.  This might
be because they are reference counted, managed by the system
(Snarfs?), or always manually deleted (Orgls).

   Much as I approve of the general attitude that we should make
   programming at one level simpler by investing in abstractions and
   creating more powerful, simpler building blocks at a lower level, I
   fear we may be on the far side of the trade-off this time.  How
   painful would it be to explicitly delete the old Table when you want
   copy-on-write to be able to write without copying.  Note that a
   regular garbage collector will still let you postpone figuring out
   when and where to put these deletes; just at the cost of actually
   copying sometimes when you didn't need to.  If it's at least
   *plausible* that we can figure out where we *need* to put these
   deletes (i.e., where they *actually* make a *significant* difference),
   then let's postpone adding yet more complexity to our garbage
   collector requirements until we find we need to.

This violates the design principle "0,1,Infinity".  We either have to
worry about storage management or we don't.  You can't explicitly
delete the old Table because it might be held onto somewhere else,
(but probably not).  The cost for a regular garbage collector would be
ALWAYS copying when you typically don't need to.  Onteresting notion:
The need for explicit deletes changes my mental model from
side-effect-free to side-effecting.  That's my real objection.
Amusing.  Also, I don't think it's any harder for garbage collecting.

   Btw, before this example, it never occured to me before to make a
   distinction between immediate collectors and eventual collectors.

Or the combination, based on type.

dean