UnaryFns & Tables

[Eric Dean Tribble <tribble>]

and have exactly the same properties, so they should be the same      1) Don't use the word occlude.  That has too many meanings in user
      interface design.  It also doesn't mean quite the right thing.  If
      nothing else, the occlusion is incidental.  The primary result is
      having a combined collection.  What's wrong with combine?

   Because it means something different than what we're already using
   "combine" for in Orgls---reject the attempt if there's a conflict.
   With tables, if there's a conflict, the receiver wins.  If you think
   we should redefine Orgl::combine to mean this too, then we should
   consider using this term for Tables.  Otherwise it just creates
   confusion.  Besides, "occlude" seems assymetrical, and "combine" seems
   symmetrical.

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

      2) I don't want to unify Tables and UnaryFns.  It corresponds to
      keeping your mind so open your brains fall out.  It's easy to
      understand Tables.  It's easy to understand UnaryFns.  It's not easy
      to understand count for a UnaryFn, or coordinateSpace, for that
      matter.  That makes both abstractions less useful.  I've been quite
      surprised and extremely annoyed when I invented an abstraction to
      general and powerful for most of my problems.

The last comment was anecdotal, not directed at your suggestion.
Realize that coments get more direct as I type faster.  Sorry.

   I'm sympathetic to this.  My problem is: is it always clear when I
   want a given mapping to be a Table, and when I want it to be a
   UnaryFn.  If you can articulate a clear criteria I can use to decide
   the cases I come across, that'll be interesting.  Criteria like "this
   feels like a function, but that feels like a table" are not
   interesting.

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?

Can you think of any other differences in usage that derive from a
difference in desired protocol?

   Sometimes forcing a conceptual unification of things that feel
   different but have very similar formalisms creates power and
   generality.  Note the Scheme decision to unify the name spaces for
   variables & functions, or to unify procedure calling and loops.

Names for functions and names for variables provide exactly the same
service.  Therefore it's unrelated.  They didn't unify procedure
calling and loops in scheme, they eliminated special loop constructus
because they could do loops with procedure calls.  Again, unrelated.
Let's not continue this argument, though.

   Recall Alan Kay's dictum:  "Similar features should be made either
   completely different, or the same".  

I agree.  Answering the above differences will be instructive one way
or the other.  I suspect we'll want to make them completely different.
Note that this principle applies more to the description than to the
functionality.  A well designed class might have one name with
associated semantics and usage.  It could also masquerade under
another name with a different semantics and usage.  If the semantics
and usages were sufficiently distinct and understandable, it wouldn't
break the above principle.  (If I ever discover such a thing, I'll let
you know :-)

   How did coordinateSpaces enter the picture?

As noted above for Tables.

dean