UnaryFns & Tables

[Mark S. Miller <mark>]

Date: Mon, 23 Oct 89 16:20:27 PDT
   From: tribble (Eric Dean Tribble)

   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.

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

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.

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.
Recall Alan Kay's dictum:  "Similar features should be made either
completely different, or the same".  

(Note that I have here exercised the new "freedom" granted by recent
legal decisions: the previous quote is just a well-intentioned
paraphrase.  I don't remember what precisely he said.)

How did coordinateSpaces enter the picture?