EQUAL, and hash tables, and value/object distinctions

[jrose@Sun.COM (John Rose)]

   Date: Mon, 18 Jul 88 23:38:35 PDT
   From: Jon L White <edsel!jonl@labrea.stanford.edu>

   [have been out of town for some time, and under other time constraints,
   so apologies in advance for replying to "old mail"]

   re: First, if EQUAL is going to descend structures and arrays to test
       for isomorphism, it should compare hash tables for equality
       according to their contents.  That is, it should verify
       that two possibly-equal hash tables have the same set of
       keys, and that for each key the two stored values are EQUAL.
       Key equality testing must be done using each table's
       key comparison function.

   That's a lot of very strong words for what must be considered an
   opinion on how EQUAL could be extended to the case of hash-tables.
   The difficulty is that EQUAL has, until now, been a very low-level
   simple-minded component-wise equivalence test.  What you are proposing 
   is something that looks much more grandiose than even EQUALP.

I think you missed my point.  Let me try saying it with fewer
strong words.  EQUAL currently recurs on the components of
CONS cells, and a few other types.  There are proposals in
the air to add to the set of types whose components EQUAL
compares recursively.  These types include arrays and structures.
I personally find these proposals rather aggressive or "grandiose",
as perhaps you do too.  However, __if__ it makes overall sense
to treat the components of arrays and structures this way,
I believe it also makes sense to treat hash table components
in the same way, using a suitable definition of "component".

My contribution, I hope, is to point out that hash tables
do in fact have components quite analogous to array
or structure components, that these components are
the hash table's values, accessed using its keys,
and finally that this implies certain things about
the way hash table isomorphism is computed.

				-- John