EQUAL

[Jim McDonald <edsel!jlm@labrea.stanford.edu>]

>                        Look at the definition of ATOM on pg. 73 ("is
>  not a CONS"); it says nothing about the notion of atominicity.  How
>  sensible is it to view an array as "atomic"?

I think most of the confusion with EQUAL may stem from the fact that
the syntax of lisp programs is expressed with lists.  When modifying 
programs, writing macros, etc. it is critical to have primitives that
are sensitive to the components of your code, which effectively means
having primitives that are sensitive to the components of lists.
[Thus, to answer the question posed above, when transforming a lisp
program, arrays are atomic since they express no syntactic control
information.]  There is no comparable historical reason for similar
access to the contents of strings, arrays, structures, etc.  

Thus EQUAL is (in some historical sense) defined to make it easy to do
pattern matching on code.  Since code traditionally becomes read-only,
this is more-or-less consistent with collapsing EQUAL structures to be
EQ.  I claim that the traditional explanation for EQUAL's semantics
(that EQUAL means roughly HAVE-THE-SAME-PRINT-REPRESENTATION-P) is
actually just an observation based on this more fundamental reason. 

When people try to move beyond manipulation of code, the whole basis
for the semantics of EQUAL is removed, so the result is somewhat
chaotic. 

Overall, I'll argue that you must first decide what you are trying to
do (transform code, manipulate databases, build parse trees, etc.)
before you can decide what you want of your equality predicates. 
Since Common Lisp presumably is not dedicated to any particular
application (except that code transformations should be supported),
I'm pessimistic that people will ever agree on simple semantics.
Also, since people in general have some esthetic sensibilities, a
fully haired roll-your-own equality predicate seems unlikely.

Since code transformation is common to almost all lisp endeavors,
EQUAL and friends should first be tested for usefulness in that
context.  Then, if someone can define another similar class of
endeavors, perhaps another set of predicates can be defined to capture
the semantics needed there.  So far, I have seen no coherent
description of generic data transformations, let alone one that would
warrant modification of the language.

  jlm