Why is #'equalp not allowed in make-hash-table ?

[edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)]

About a year or so ago, there were two points about hash-tables receiving 
heavy discussion:
  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 --