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