EQUAL

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

   While this all sounds very nice, I'm afraid you're engaging in
   a bit of historical revisionism.

After hitting <return> I had second thoughts along those lines, but 
third thoughts removed them.  (Now I'm afraid to hit return again. :-)

   Originally, LISP didn't have all these nice hairy datatypes.
   Those of us who were there (Not me!) can tell about what McCarthy
   wrought, but I know I've seen Lisp's without arrays at all.  

No fair.  That's an argument for my position.

                                                                I know
   people have been using EQUAL to compare data more often than to compare
   code for a very long time.

One of the tenants of evolution is that rather small advantages can drive
natural selection.  If EQUAL and EQUAL' are of comparable utility for
comparing data, but EQUAL is much better for code, then EQUAL will
prevail, even if 99% of the comparisons are for data.  

   In fact, EQUAL doesn't work on code, plain and simple.  To compare
   code, you must first recognize that it is not computable to compare
   two functions which contain quoted data, unless that quoted data is
   EQ.  You also have to place constraints on macros to not be pathological
   (i.e. sick).

But EQUAL *does* work on code.  E.g., I might have a rewrite system in
my compiler that makes all sorts of modifications and then checks to
see if the result is EQUAL.  If not, it goes around again.  Since the
code analysis is using CAR, CDR, CONS, LIST, etc. and never copying
arrays or other objects, EQUAL is precisely the right test. 

Textbook arguments and pathological examples miss the historical point
I was making.  My sense is that the early implementers were pragmatic
enough not to fall into the trap of avoiding something useful because
it was not (and could never be) perfect.

   In short, what EQUAL is good for is comparing "old-style" data
   (that is, data structures like are used in such venerable programs
   as Macsyma -- and there are some exceptions there, too).

I would include "old-style" and most "new-style" code.  Another way of
phrasing my argument is that "old-style" code and data were so similar
as to blur the uses of EQUAL.  "New-style" data has evolved more, so
discrepencies are emerging between the uses.

   I do think it would be reasonable to define an extremely limited set
   of new predicates.  I would suggest limiting it to two new ones that
   do the two pieces of EQUALP -- descend other structures, and merge
   case in strings and characters.

I agree with the focus, but probably not the details.

   I would strongly discourage any attempt to "solve the problem of
   comparisons", on the grounds that it will require more hair, additions
   to the language, and discussion than it could possibly be worth.

Agreed!

  jlm