Re: Tables returning nil if no value

[Ashwin Ram <ram@YALE.ARPA>]

    I hesitate to offer an alternative to "the correct solution", but in our
    hash table (HT) package here at UCLA, we have nil as the undefined value and
    an additional function, HT:KEY? that returns true if the key is defined in
    the table (even with a nil value) and false otherwise.  This has the advantage
    that you can ignore the defined/undefined issue if you'd like.  In general,
    our solution has been to have the application (built on top of HT) decide
    about the defined/undefined question.
    
I agree.  My philosophy is always to let the user decide about the sticky
issues, while providing a clean way to implement the outcome of the decision.


                               ...The default hashing function is OBJECT-HASH,
    but the user can define another (as well as the equality predicate) in the
    call to HT:CREATE.
    
This is also in concord with my philosophy.  Provide nice defaults but never
sacrifice extensibility.  For the HT problem, the hashing and equality functions
are the obvious examples of this.  (I was surprised not to see functions
in your list that get the hashing and equality functions for an HT.)


    The unobvious ones:
    
            HT:FIND-ENTRY -- returns the first pair that satisfies a predicate.
            HT:ADD/UPDATE -- add assumes the key is new, update the key is old.

HT:FIND-ENTRY (along with HT:MAP) don't seem to make much sense.  What does
"the FIRST pair" mean?  What significance would the order of entries returned
by HT:MAP have?  Entries in a table don't have any endogenous order.  HT:WALK,
by contrast, is fine (if you're into side-effects).  It might be useful to
make HT:MAP return a table (in the obvious way, so that (COPY ht) is just
(HT:MAP IDENTITY ht)).

-- Ashwin.
-------