Re: Tables returning nil if no value

[Ashwin Ram <ram@YALE.ARPA>]

        Date: 27 Mar 86 11:38:39 EST (Thu)
        From: Ashwin Ram <ram at YALE.ARPA>
    
        I would vote for a predicate TABLE-ENTRY? (like Scott's HT:KEY?) which checks
        whether K has an association in T.
    
    This sort of conflicts with my design which for (set (table-entry foo
    bar) '#f) deletes bar's entry in the table; if there's a possibility of
    having an entry of #f being different from no entry, then you have to
    have a separate deletion primitive.  Things get out of hand quickly --
    once you have one feature you want a zillion others.  I say nip them in
    the bud.
    
    Jonathan.
    

    
In practical terms I agree with you.  I've been using tables (and even property
lists) for a long time without ever being bothered by the "nil vs. doesn't-exist"
distinction.  In the few cases where it matters, it's easy enough to write a
couple of one-liners to handle the situation.  For the same reason I'm quite
happy with ASS returning nil for non-existent entries and a cons cell otherwise,
and using these interchangeably as boolean and list values.

In the case of tables, however, a strong (theoretical) case could be made for
having a separate TABLE-ENTRY? predicate (along with the REMOVE-TABLE-ENTRY
primitive it necessitates).  I expect to hear a million voices claiming that
they would like to be able to store nil (or #f) explicitly in a table as a
value in its own right.  Making (set (table-entry tbl key) '#f) automatically
delete the entry may be problematic (for a sample, what is the size of the
table after you've entered one #t and five #f's into it?  One or six?  What
if you now set the one #t entry to #f?  Do you now have an empty table?)

One of these days we'll move on to three-valued logics and then everyone
will be happy :-).

-- Ashwin.


-------