UnaryFns & Tables

[Mark S. Miller <mark>]

Date: Wed, 25 Oct 89 23:17:12 PDT
   From: tribble (Eric Dean Tribble)

   'Occlude' makes me itch.  Here's some alternatives:  combine, atop,
   withAll, addAll, join, joinAll, compose, storeAll.  My favorite is to
   use the name of the operation for replacing or copying with one extra
   key-value pair and adding 'All' to it.  That would be 'storeAll',
   'introduceAll', or 'replaceAll' for MuTables, and 'withAll' or some
   such for ScruTables.

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".

   Here's a couple:  'Do I care about the count of the domain?'  If so,
   then a table is appropriate.  'Is it a map from Positions to Objects or
   from Objects to Objects?'  Remember that Tables only map from
   Positions in a given CoordinateSpace (this is where CST come up
   below).  

   Here's a major difference that probably cannot be formalized: Tables
   map from particular positions (a particular set of keys) into some
   fixed set of objects.  UnaryFns map from an infinite set of objects
   that have some property into an infinite range of objects related to
   the domain objects.

   Finally, it's easy to describe the relation between UnaryFns and
   BinaryFns.  What's the relation between BinaryFns and Tables?

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?