[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: edsel!jonl@labrea.stanford.edu*Subject*: EQUAL, and hash tables, and value/object distinctions*From*: jrose@Sun.COM (John Rose)*Date*: Tue, 19 Jul 88 13:30:51 PDT*Cc*: goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu*In-reply-to*: Jon L White's message of Mon, 18 Jul 88 23:38:35 PDT <8807190638.AA05670@bhopal.lucid.com>

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

**Follow-Ups**:**EQUAL, and hash tables, and value/object distinctions***From:*Jon L White <edsel!jonl@labrea.stanford.edu>

**References**:**EQUAL, and hash tables, and value/object distinctions***From:*Jon L White <edsel!jonl@labrea.stanford.edu>

- Prev by Date:
**Question about readtable null arguments** - Next by Date:
**EQUAL, and hash tables, and value/object distinctions** - Previous by thread:
**EQUAL, and hash tables, and value/object distinctions** - Next by thread:
**EQUAL, and hash tables, and value/object distinctions** - Index(es):