[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Why is #'equalp not allowed in make-hash-table ?
About a year or so ago, there were two points about hash-tables receiving
1) Why not permit any predicate of two arguments as the :test argument
2) Why not permit explicit specification of the "sxhashing" function.
Several implementations, Lucid's included, have the capability of doing
(1) with no extra work. However, the question posed by (2) raises the
issue of consistency between the "numericalizing" function [i.e., whatever
you might use in place of sxhash] and the "equivalencing" function [i.e.,
whatever you might use in place of equal].
Although there didn't seem to be general consensus on the issue, the
proposal that seemed most consistent to me was:
(A) Extend Common Lisp hash-tables to permit any two-argument predicate
to be used as a :test function; and add an :sxhash argument which
specifies the function to reduce an s-expression into the integer
used in computing the collision chains (assuming you hash that way).
(B) The default for the :sxhash argument for EQ/EQL type tables can be
something internal (probably not documented or exported); the
default for any other :test argument will be #'equal.
This permits the extensions without having to address the issue of having
a function which computes the address of a pointer (for EQ/EQL tables).
Along that line I wonder why the default isn't :test = #'EQUAL, rather
than #'EQL? (or better yet, #'EQUALP). The EQ/EQL semantics is almost
never right when the table contains "complex" structures like lists,
vectors, defstructs and so on, and typically has unfortunate consequences
for relocating garbage collectors. Yet an EQUAL table can be just as
"speedy" as an EQ/EQL one when the entries aren't such "complex" entities;
so one should never try to switch semantics merely for "speed". This
doesn't say that there is no place for EQ/EQL tables -- merely that they
are often used for the wrong reasons.
-- JonL --