``` Subject: Re: (eql x y) = T and (equal x y) = NIL From: rpw3@rpw3.org (Rob Warnock) Date: Wed, 11 Feb 2009 18:45:47 -0600 Newsgroups: comp.lang.lisp Message-ID: <k8GdnfTxHIym7A7UnZ2dnUVZ_gGWnZ2d@speakeasy.net> ```
```Thomas A. Russ <tar@sevak.isi.edu> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| > EQUAL is deep structural equality on a very few specified types:
| >   it only "descends into" conses, arrays, and pathnames.
|
| Not quite correct. EQUAL doesn't descend into arrays other than strings.
+---------------

Ouch! You're quite correct! [Well, if you also add bit vectors.]
Sorry 'bout that! I skimmed CLHS "Function EQUAL" just a little
too hastily, and keyed off the "Arrays" paragraph heading without

Arrays
Two arrays are equal only if they are eq, with one exception:
strings and bit vectors are compared element-by-element (using eql).
If either x or y has a fill pointer, the fill pointer limits the
number of elements examined by equal. Uppercase and lowercase
letters in strings are considered by equal to be different.

Once more, with feeling:  ;-}

EQ is object identity.
EQL is "sameness" (EQ plus "same" type/value characters & numbers).
EQUAL is deep structural equality on a very few specified types:
it only "descends into" conses, strings, bit vectors, and pathnames.
EQUALP is like EQUAL but additionally "descends into" general arrays,
structures, and hash tables as well, and it also ignores case
on characters/strings and specialization in arrays [e.g., the
string "abc" and the simple vector #(#\A #\B #\C) are EQUALP].

Is that better?

-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607

```