UnaryFns & Tables

[Eric Dean Tribble <tribble>]

I have no attachment to "occlude", I was just arguing against
   "combine".  "storeAll" and its ilk implies to me that the argument
   Table is being snapshot at the time of the operation, which isn't the
   case.  Instead, the composite table's state tracks changes to the
   state of its component tables.  Perhaps this is also a poor choice of
   semantics for compositeTables.  However, if we keep the current
   semantics, then I favor "atop".

Good point about the snapshot.  Is there a corresponding operation for
Orlgs?  Is there a compelling need for dynamically tracking subTables?
If not, a snapshot semantics is MUCH clearer, and is certainly more
useful to me.  It's also easier to code.  I vote we use a snapshot
semantics. 

   I'm convinced.  We should keep UnaryFns and Tables separate, but have
   some kind of conversion ability between the two (at least a UnaryFn
   that wraps a Table, probably not the reverse).  Heh, what do you
   think? 

It was useful to clarify the differences.  I had to think about it a
moment, but then I realized the difficulaties in making a Table from a
UnaryFn.  Going one way is just fine.

dean