Did the four standard generic equality predicates come into Common
Lisp together or are they the result of merging dialects--e.g. EQUAL
came from dialect foo while EQUALP was from dialect bar?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
>
> Did the four standard generic equality predicates come into Common
> Lisp together or are they the result of merging dialects--e.g. EQUAL
> came from dialect foo while EQUALP was from dialect bar?
For what it is worth, MacLisp originally only had EQ and EQUAL.
I believe that = was added later for numeric comparisons.
I first encountered EQL in Common Lisp, but it may have been introduced
in Zetalisp. EQUALP is AFAIK a late arrival when the need for doing
vector or structural equality testing was noted and there was a desire
not to potentially break existing code by just extending the meaning of
EQUAL.
I hope someone with more of a historical background can expand or
correct this. Kent?
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
>>
>> Did the four standard generic equality predicates come into Common
>> Lisp together or are they the result of merging dialects--e.g.
>> EQUAL came from dialect foo while EQUALP was from dialect bar?
>
> For what it is worth, MacLisp originally only had EQ and EQUAL.
> I believe that = was added later for numeric comparisons.
>
> I first encountered EQL in Common Lisp, but it may have been
> introduced in Zetalisp. EQUALP is AFAIK a late arrival when the need
> for doing vector or structural equality testing was noted and there
> was a desire not to potentially break existing code by just
> extending the meaning of EQUAL.
So it looks like ZetaLisp's EQUAL was more like CL:EQUALP, at least as
far as its treatment of strings. I don't have time at the moment to
draw up a matrix but it does seem from a few quick glances at various
Lisp manuals I have lying around, that every Lisp dialect takes a few
different notions of equivalence of different data types and spreads
them across between two and four different general[1] equality
predicates whose names start with "eq".
I haven't found, in my brief search, any dialects other than Common
Lisp that have more than three general equality predicates.
-Peter
[1] General in the sense that they can be applied to any two objects.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> I haven't found, in my brief search, any dialects other than Common
> Lisp that have more than three general equality predicates.
The development version of Emacs has four general (in the sense that
they can be applied to any two objects) equality predicates:
eq, eql, equal, equal-including-properties
However, only eq and equal are documented in the manual.
John Paul Wallington <···@gnu.org> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
>> I haven't found, in my brief search, any dialects other than Common
>> Lisp that have more than three general equality predicates.
>
> The development version of Emacs has four general (in the sense that
> they can be applied to any two objects) equality predicates:
>
> eq, eql, equal, equal-including-properties
>
> However, only eq and equal are documented in the manual.
Heh, which demonstrates yet another way to slice it: Elisp's EQ is
sort of half way between CL:EQ and CL:EQL: integers with the same
value are eq but float with the same value are not though they are
eql.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: EQ, EQL, EQUAL, EQUALP history
Date:
Message-ID: <87ekiw9m1m.fsf@qrnik.zagroda>
Peter Seibel <·····@javamonkey.com> writes:
> Heh, which demonstrates yet another way to slice it: Elisp's EQ is
> sort of half way between CL:EQ and CL:EQL: integers with the same
> value are eq but float with the same value are not though they are
> eql.
But only because it does not support bignums.
I wonder what happens with tons of Emacs scripts if some day they
decide that it will have bignums. Especially as its fixnums are
ridiculously small as the only integers: 28 bits on 32-bit machines,
which suffices to load only 128MB of text.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> I wonder what happens with tons of Emacs scripts if some day they
> decide that it will have bignums. Especially as its fixnums are
> ridiculously small as the only integers: 28 bits on 32-bit machines,
> which suffices to load only 128MB of text.
I believe XEmacs recently introduced support for bignums and ratios.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: EQ, EQL, EQUAL, EQUALP history
Date:
Message-ID: <871xeu3k7g.fsf@qrnik.zagroda>
Lars Brinkhoff <·········@nocrew.org> writes:
>> I wonder what happens with tons of Emacs scripts if some day they
>> decide that it will have bignums. Especially as its fixnums are
>> ridiculously small as the only integers: 28 bits on 32-bit machines,
>> which suffices to load only 128MB of text.
>
> I believe XEmacs recently introduced support for bignums and ratios.
Ah, I didn't know. Indeed.
<http://www.tug.org/ftp/texlive/Contents/testinstalled/xemtex/doc/xemacs/xemacs-faq.html#Q5_002e4_002e4>
says that eq continues to compare physical addresses, and eql or =
should be used for numbers. So equality predicates are similar to CL,
and scripts which use eq for numbers should be fixed unless the
numbers are always small (like characters).
I guess that the buffer limit stays as at 128MB. This causes problems
with importing mailboxes into Gnus.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> <http://www.tug.org/ftp/texlive/Contents/testinstalled/xemtex/doc/xemacs/xemacs-faq.html#Q5_002e4_002e4>
> says that eq continues to compare physical addresses, and eql or =
> should be used for numbers. So equality predicates are similar to
> CL, and scripts which use eq for numbers should be fixed unless the
> numbers are always small (like characters).
In XEmacs characters aren't numbers.
> I guess that the buffer limit stays as at 128MB. This causes
> problems with importing mailboxes into Gnus.
Your guess it wrong. Both XEmacs (1GB) and CVS Emacs (256MB) have
higher limits than that.
--
Johan Bockg�rd
From: Christopher C. Stacy
Subject: Re: EQ, EQL, EQUAL, EQUALP history
Date:
Message-ID: <u8y986la2.fsf@news.dtpq.com>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> >
> > Did the four standard generic equality predicates come into Common
> > Lisp together or are they the result of merging dialects--e.g. EQUAL
> > came from dialect foo while EQUALP was from dialect bar?
>
> For what it is worth, MacLisp originally only had EQ and EQUAL.
> I believe that = was added later for numeric comparisons.
>
> I first encountered EQL in Common Lisp, but it may have been introduced
> in Zetalisp. EQUALP is AFAIK a late arrival when the need for doing
> vector or structural equality testing was noted and there was a desire
> not to potentially break existing code by just extending the meaning of
> EQUAL.
Zetalisp originally only had EQ, EQUAL, and =.
(Well, we also had "not =", whose glyph is = with a line through it.)
Zetalisp got EQL and EQUALP sometime between 1981 and 1984.
Peter Seibel <·····@javamonkey.com> writes:
> Did the four standard generic equality predicates come into Common
> Lisp together or are they the result of merging dialects--e.g. EQUAL
> came from dialect foo while EQUALP was from dialect bar?
There are some interesting threads on this in Google.
In one, KMP points out that eq and eql are essentially the same
function, with eq available as an optimization for
non-numeric/non-char values. See:
http://www.google.com/groups?hl=en&lr=&threadm=87u1vts33r.fsf%40pps.jussieu.fr&rnum=4&prev=/groups%3Fhl%3Den%26lr%3D%26q%3Dcomp.lang.lisp%2Beq%2Beql%2Bequal%26btnG%3DSearch
That would leave us with three eq/eql, equal and equalp.
In his Parenthetically Speaking article about copying and equality,
KMP also indicates that the choice of how equal and equalp work was
arbitrary, but done with the idea of maintaining compatibility with
existing implementations. See:
http://www.nhplace.com/kent/PS/EQUAL.html
Combining this with the information that you've dug up so far
(about no dialect having more than 3 equality predicates), I'd say
that, if we can trust KMP and treat eq/eql as essentially the same
function, then CL has only 3 predicates as well (with a speed
optimization version of eql for those that need it).
CLTL2 says:
"eq and equal have the meanings traditional in Lisp. eql was
added because it is frequently needed, and equalp was added
primarily in order to have a version of equal that would ignore
type differences when comparing numbers and case differences when
comparing characters." (p 103)
"The CL function eql is similar to the Interlisp function eqp.
However, eql considers 3 and 3.0 to be different, whereas eqp
considers them to be the same; eqp behaves like the CL =
function, not like eql, when both arguments are numbers." (p 104)
"In Lisp Machine Lisp, equal ignores the difference between
uppercase and lowercase letters in strings. This violates the
rule of thumb about printed representations, however, which is
very useful, especially to novices. It is also inconsistent with
the treatment of single characters, which in LML are represented
as fixnums." (p 107)
So, I'd say that eq/equal are normal equality predicates. eql was
added for convenience. equalp was added to be compatible with the
LML equal.
--jon