[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tables returning nil if no value
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
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 :-).