tables and Becomes

[heh <heh@xxxxxxxxxx>]

Subject:                               Time:13:36
  OFFICE MEMO          tables and Becomes                     Date:8/24/90
  In a discussion with MarkM on Weds, (thurs?) about Becomes, we struck on how
well Becomes simplifies efficient table implementions.  For example,
TinyArray's are very easy, and they can become XuArrays automatically.  Also,
the copy-on-write-read implementations will be very easy.
  This morning, I thought of another thing.  Something that has always bothered
me about the table implementations was that some are more specific (will BLAST
if a less specific operation is attempted).  Well, now we have the means to fix
this, but I don't think it will be worth it.  Here is the discussion.
  One of the restrictions of the Becomes mechanism is that for any class that
can become another class, that class can only be dealt with as a common
superclass to both classes.  For example, an IntegerTable (if it could become a
HashTable) could only be used as a MuTable.  Therefore, some of the specific
IntegerTable protocol would either need to be moved to MuTable, or dropped.
  This one is probably not a problem, but XuWordArray has the special protocol
->gutsOf ().  This is necessary in order to keep front-ends moderately
efficient.  We could get around this by having the fe CONVERT the table to
another form, which could provide the gutsOf message.  I kind of like this,
because we could then make XuWordArray an ImmuTable class like it really should
be (it is not ImmuTable because the internals are accessible, and therefore
alterable...).
  One of the major downsides to doing all this would be quite a few type
changes in the code.  A lot of IntegerTable's and Array's would have to become
MuTable's.  This would wreak compile-havoc for a while.  Also, a fair amount of
table code would need modification to handle the automatic type Become'ing
when, for example, a HeaperAsPosition is inserted into an IntegerTable.
  A major positive side of this is that the Table classes would be more
general.  The implementations such as IntegerTable and XuArray, which are
present primarily to provide more efficient implementations for those special
cases which are used a lot (like Integer domain, or PackOBits range).  These
tables would automatically become a more general table if, for example, a
HeaperAsPosition key were inserted.  Should they also become more specific if
possible? (a much harder problem, of course, because the specific
implementations aren't always known...)

  Well, my recommendation is that we keep the table hierarchy the way it is
(except, possibly, for XuWordArray...).  Since we currently have no place in
the code (that I know of) where the domain or the range needs to become more
general (automatically), and most places where the domain or range is specific
are that way because they will forever and always be specific, we should not
mess with this.

--Hugh