On Feb 10, 7:31 pm, pereges <·······@gmail.com> wrote:
> Can some one please show me an example of this case ? (x and y can be
> sustituted)
SW-MVC> (values (eql (list 1 2) (list 1 2))
(equal (list 1 2) (list 1 2)))
NIL
T
..this eq, eql, equal stuff is very useful actually. If you want a
generic equality-test (but you don't always want this), use a generic
function.
> What exactly is the difference between eql and equal ?
http://www.lispworks.com/documentation/HyperSpec/Body/f_eql.htm (see
`See Also').
On Feb 10, 11:00 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> SW-MVC> (values (eql (list 1 2) (list 1 2))
> (equal (list 1 2) (list 1 2)))
> NIL
> T
>
> ..this eq, eql, equal stuff is very useful actually. If you want a
> generic equality-test (but you don't always want this), use a generic
> function.
This is for (eql x y) = NIL and (equal x y) = T
I wanted to see an example with (eql x y) = T and (equal x y) = NIL.
I've tried a few example and didn't have success. Is this case even
possible ??
> > What exactly is the difference between eql and equal ?
>
> http://www.lispworks.com/documentation/HyperSpec/Body/f_eql.htm(see
> `See Also').
thanks for the link
pereges <·······@gmail.com> writes:
> On Feb 10, 11:00��am, Lars Rune N��stdal <···········@gmail.com> wrote:
>
> > �� SW-MVC> (values (eql �� (list 1 2) (list 1 2))
> > �� �� �� �� �� �� �� �� �� (equal (list 1 2) (list 1 2)))
> > �� NIL
> > �� T
> >
> > ..this eq, eql, equal stuff is very useful actually. If you want a
> > generic equality-test (but you don't always want this), use a generic
> > function.
>
> This is for (eql x y) = NIL and (equal x y) = T
>
> I wanted to see an example with (eql x y) = T and (equal x y) = NIL.
> I've tried a few example and didn't have success. Is this case even
> possible ??
This case is not possible.
(EQ x y) ==> (EQL x y) ==> (EQUAL x y) ==> (EQUALP x y)
where "==>" means logical implication. Each equality predicate moving
to the right includes more objects in its equivalence class, so anything
that satisfies something to the left is included.
The best you can do is the following:
(= 1 1.0) = T
(EQUAL 1 1.0) = NIL
--
Thomas A. Russ, USC/Information Sciences Institute
pereges schrieb:
> On Feb 10, 11:00 am, Lars Rune N�stdal <···········@gmail.com> wrote:
>
>> SW-MVC> (values (eql (list 1 2) (list 1 2))
>> (equal (list 1 2) (list 1 2)))
>> NIL
>> T
>>
>> ..this eq, eql, equal stuff is very useful actually. If you want a
>> generic equality-test (but you don't always want this), use a generic
>> function.
>
> This is for (eql x y) = NIL and (equal x y) = T
>
> I wanted to see an example with (eql x y) = T and (equal x y) = NIL.
> I've tried a few example and didn't have success. Is this case even
> possible ??
>
>>> What exactly is the difference between eql and equal ?
>> http://www.lispworks.com/documentation/HyperSpec/Body/f_eql.htm(see
>> `See Also').
>
> thanks for the link
You should have followed it.
There you would have found the link to equal. And in that description
you would have found one requirement, which the ANSI Standard makes:
�Any two objects that are eql are also equal.�
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Lars Rune N�stdal wrote:
> ..this eq, eql, equal stuff is very useful actually.
Except for that the function names don't say what results to expect
(except for the trite property that the longer names are less specific.)
pereges wrote:
> Can some one please show me an example of this case ? (x and y can be
> sustituted)
>
> What exactly is the difference between eql and equal ?
Such an example doesn't exist: (eql x y) implies (equal x y)
Also: (eq x y) implies (eql x y)
And probably: (equal x y) implies (equalp x y)
Since this is transitive, this also means: (eq x y) implies (equalp x y)
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Le Tue, 10 Feb 2009 10:31:43 -0800 (PST),
pereges a écrit :
> Can some one please show me an example of this case ? (x and y can be
> sustituted)
> (eql x y) = T and (equal x y) = NIL
> What exactly is the difference between eql and equal ?
EQL compare adresses (like EQ), char and numbers of same cast.
EQUAL same as EQL but it compare the structure of objects.
That said, AFAIK, EQL implies always EQUAL. The reverse is not
true, two lists can be EQUAL (same content) but not EQL (not
the same address).
See :
<http://www.lispworks.com/documentation/HyperSpec/Body/f_eql.htm>
<http://www.lispworks.com/documentation/HyperSpec/Body/f_equal.htm>
--
Jacques.
From: Thomas A. Russ
Subject: Re: Difference beetween eql and equal (was: (eql x y) = T and (equal x y) = NIL)
Date:
Message-ID: <ymiy6wd22hj.fsf@blackcat.isi.edu>
Kojak <·······@janville.Borg.invalid> writes:
> Le Tue, 10 Feb 2009 10:31:43 -0800 (PST),
> pereges a ��crit :
>
> > Can some one please show me an example of this case ? (x and y can be
> > sustituted)
> > (eql x y) = T and (equal x y) = NIL
> > What exactly is the difference between eql and equal ?
>
> EQL compare adresses (like EQ), char and numbers of same cast.
> EQUAL same as EQL but it compare the structure of objects.
Actually, only the structure of CONSes.
For arbitrary sequences, you need EQUALP, but it still doesn't compare
the equality of arbitrary objects. It does, IIRC, do defstructs,
though.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Pascal J. Bourguignon
Subject: Re: (eql x y) = T and (equal x y) = NIL
Date:
Message-ID: <87iqnic7x0.fsf@galatea.local>
pereges <·······@gmail.com> writes:
> Can some one please show me an example of this case ? (x and y can be
> sustituted)
No, nobody can show you such an example. It is impossible.
On the other hand, we have always (or (not (eql x y)) (equal x y))
(loop :for (x y) :in '((1 0)
(1 1)
(1 1.0)
(abc abc)
(abc def)
("abc" "abc")
("abc" "ABC")
((1 2 3) (1 2 3))
;; ... you can put anything here
((1 2 3) ha!))
:always (or (not (eql x y)) (equal x y)))
--> T
> What exactly is the difference between eql and equal ?
Coarsely,
EQL is the identity,
EQUAL is the shallow structural equality,
EQUALP is the deep structural equality.
For the details, read their Hyperspec page, where their behavior is
precisely specified for each type of argument.
--
__Pascal Bourguignon__
Pascal J. Bourguignon <···@informatimago.com> wrote:
+---------------
| pereges <·······@gmail.com> writes:
| > What exactly is the difference between eql and equal ?
|
| Coarsely,
| EQL is the identity,
| EQUAL is the shallow structural equality,
| EQUALP is the deep structural equality.
+---------------
Slightly less coarsely:
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, arrays, and pathnames.
EQUALP is like EQUAL but additionally "descends into" structures and
hash tables as well, and it also ignores case on characters/strings.
When in doubt, use EQL. That's what the CLHS means by "same", by default.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Pascal J. Bourguignon <···@informatimago.com> wrote:
> +---------------
> | pereges <·······@gmail.com> writes:
> | > What exactly is the difference between eql and equal ?
> |
> | Coarsely,
> | EQL is the identity,
> | EQUAL is the shallow structural equality,
> | EQUALP is the deep structural equality.
> +---------------
>
> Slightly less coarsely:
>
> 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, arrays, and pathnames.
Not quite correct. EQUAL doesn't descend into arrays other than
strings. In particular, you can get
(equal #(1 2 3 4) #(1 2 3 4)) => NIL
> EQUALP is like EQUAL but additionally "descends into" structures and
> hash tables as well, and it also ignores case on characters/strings.
>
> When in doubt, use EQL. That's what the CLHS means by "same", by default.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ <···@sevak.isi.edu> wrote:
+---------------
| ····@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
reading it completely:
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.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Thomas A. Russ <···@sevak.isi.edu> wrote:
> +---------------
> | ····@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.]
Hmmm. Even after 30+ years, you still learn some new details about the
language. I wasn't aware of the bit vector part.
--
Thomas A. Russ, USC/Information Sciences Institute
····@rpw3.org (Rob Warnock) writes:
> Pascal J. Bourguignon <···@informatimago.com> wrote:
> +---------------
> | pereges <·······@gmail.com> writes:
> | > What exactly is the difference between eql and equal ?
> |
> | Coarsely,
> | EQL is the identity,
> | EQUAL is the shallow structural equality,
> | EQUALP is the deep structural equality.
> +---------------
>
> Slightly less coarsely:
>
> EQ is object identity.
> EQL is "sameness" (EQ plus "same" type/value characters & numbers).
I don't agree.
EQ compares _representation_ identity.
EQL compares object identity.
(EQ 1 1) --> NIL means that the same object, the integer 1, may have
two different instances of its representation. But there is only one
object, the integer 1.
Duplicating object represenations is an optimization allowed, that
implemetentation can easily do on immutable objects of size smaller
than that of a pointer. But in all cases, it's always the same single
object, with its single identity.
> When in doubt, use EQL. That's what the CLHS means by "same", by default.
--
__Pascal Bourguignon__
Pascal J. Bourguignon <···@informatimago.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > Pascal J. Bourguignon <···@informatimago.com> wrote:
| > +---------------
| > | Coarsely,
| > | EQL is the identity,
| > | EQUAL is the shallow structural equality,
| > | EQUALP is the deep structural equality.
| > +---------------
| >
| > Slightly less coarsely:
| >
| > EQ is object identity.
| > EQL is "sameness" (EQ plus "same" type/value characters & numbers).
|
| I don't agree.
|
| EQ compares _representation_ identity.
| EQL compares object identity.
|
| (EQ 1 1) --> NIL means that the same object, the integer 1, may have
| two different instances of its representation. But there is only one
| object, the integer 1.
+---------------
I likewise beg to differ:
> (eq 536870912 536870912)
NIL
> (eql 536870912 536870912)
T
>
Clearly, here 536870912 and 536870912 are *different* objects!
But they are the same type (INTEGER) and value as numbers,
therefore EQL.
+---------------
| Duplicating object represenations is an optimization allowed, that
| implemetentation can easily do on immutable objects of size smaller
| than that of a pointer. But in all cases, it's always the same single
| object, with its single identity.
+---------------
I think you have this backwards. Rather, it is the case that
*different* objects (not EQ) may be the "same" under EQL.
The two object instances above of the *value* 536870912
[READ at different times and allocted different locations
in memory] are the "same" under EQL... because EQL is defined
that way (clause #2 in CLHS "Function EQL").
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Pascal J. Bourguignon <···@informatimago.com> wrote:
> +---------------
> | ····@rpw3.org (Rob Warnock) writes:
> | > Pascal J. Bourguignon <···@informatimago.com> wrote:
> | > +---------------
> | > | Coarsely,
> | > | EQL is the identity,
> | > | EQUAL is the shallow structural equality,
> | > | EQUALP is the deep structural equality.
> | > +---------------
> | >
> | > Slightly less coarsely:
> | >
> | > EQ is object identity.
> | > EQL is "sameness" (EQ plus "same" type/value characters & numbers).
> |
> | I don't agree.
> |
> | EQ compares _representation_ identity.
> | EQL compares object identity.
> |
> | (EQ 1 1) --> NIL means that the same object, the integer 1, may have
> | two different instances of its representation. But there is only one
> | object, the integer 1.
> +---------------
>
> I likewise beg to differ:
>
> > (eq 536870912 536870912)
>
> NIL
> > (eql 536870912 536870912)
>
> T
> >
>
> Clearly, here 536870912 and 536870912 are *different* objects!
> But they are the same type (INTEGER) and value as numbers,
> therefore EQL.
No they are the same object, with the same identity. Numbers are
IDENTIFIED by their value.
Remember, numbers are equivalence classes. You may choose any
representant to designate the class, but the uniquely identified
mathematical and lisp OBJECT, IS the equivalence class, not the
representant.
> +---------------
> | Duplicating object represenations is an optimization allowed, that
> | implemetentation can easily do on immutable objects of size smaller
> | than that of a pointer. But in all cases, it's always the same single
> | object, with its single identity.
> +---------------
>
> I think you have this backwards. Rather, it is the case that
> *different* objects (not EQ) may be the "same" under EQL.
No this is not possible. If they are EQL then they are the very same
object, identically.
> The two object instances above of the *value* 536870912
> [READ at different times and allocted different locations
> in memory] are the "same" under EQL... because EQL is defined
> that way (clause #2 in CLHS "Function EQL").
There is no way you can distinguish, in a OO sense, 536870912 and
536870912. This is because they are immutable. If you could flip a
bit of an integer, then perhaps we could have two different objects
with a value slot pointing to possibly different integers. But since
you can't, you can't and they're one single object.
--
__Pascal Bourguignon__
On Feb 11, 4:46 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ····@rpw3.org (Rob Warnock) writes:
> > Pascal J. Bourguignon <····@informatimago.com> wrote:
> > +---------------
> > | ····@rpw3.org (Rob Warnock) writes:
> > | > Pascal J. Bourguignon <····@informatimago.com> wrote:
> > | > +---------------
> > | > | Coarsely,
> > | > | EQL is the identity,
> > | > | EQUAL is the shallow structural equality,
> > | > | EQUALP is the deep structural equality.
> > | > +---------------
> > | >
> > | > Slightly less coarsely:
> > | >
> > | > EQ is object identity.
> > | > EQL is "sameness" (EQ plus "same" type/value characters & numbers).
> > |
> > | I don't agree.
> > |
> > | EQ compares _representation_ identity.
> > | EQL compares object identity.
> > |
> > | (EQ 1 1) --> NIL means that the same object, the integer 1, may have
> > | two different instances of its representation. But there is only one
> > | object, the integer 1.
> > +---------------
>
> > I likewise beg to differ:
>
> > > (eq 536870912 536870912)
>
> > NIL
> > > (eql 536870912 536870912)
>
> > T
>
> > Clearly, here 536870912 and 536870912 are *different* objects!
> > But they are the same type (INTEGER) and value as numbers,
> > therefore EQL.
>
> No they are the same object, with the same identity. Numbers are
> IDENTIFIED by their value.
>
> Remember, numbers are equivalence classes. You may choose any
> representant to designate the class, but the uniquely identified
> mathematical and lisp OBJECT, IS the equivalence class, not the
> representant.
>
> > +---------------
> > | Duplicating object represenations is an optimization allowed, that
> > | implemetentation can easily do on immutable objects of size smaller
> > | than that of a pointer. But in all cases, it's always the same single
> > | object, with its single identity.
> > +---------------
>
> > I think you have this backwards. Rather, it is the case that
> > *different* objects (not EQ) may be the "same" under EQL.
>
> No this is not possible. If they are EQL then they are the very same
> object, identically.
No, sorry, you are wrong. Look up in the CL spec the definition of
the word identical:
identical:
adj. the same under eq.
By definition, Rob is correct. Two instances of 536870912 may or may
not be eq, and thus may or may not be identical. Whether or not they
are immutable, and thus indistinguishable except by address, they are,
by definition, not identical if they are not EQ.
Duane
From: Pascal J. Bourguignon
Subject: Re: (eql x y) = T and (equal x y) = NIL
Date:
Message-ID: <87mycsbtte.fsf@galatea.local>
·····@franz.com writes:
> On Feb 11, 4:46�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> No this is not possible. �If they are EQL then they are the very same
>> object, identically.
>
> No, sorry, you are wrong. Look up in the CL spec the definition of
> the word identical:
>
> identical:
> adj. the same under eq.
>
> By definition, Rob is correct. Two instances of 536870912 may or may
> not be eq, and thus may or may not be identical. Whether or not they
> are immutable, and thus indistinguishable except by address, they are,
> by definition, not identical if they are not EQ.
Ok. It's a question of definition, so I'm wrong per CLHS glossary.
--
__Pascal Bourguignon__
From: Marcus Breiing
Subject: Re: (eql x y) = T and (equal x y) = NIL
Date:
Message-ID: <k85jvwt9dhk68@breiing.com>
* Pascal J. Bourguignon
> Remember, numbers are equivalence classes.
Sure, just choose your numbers and equivalence relation. Meanwhile,
(EQL 2 2.0) still returns NIL...
(Yet, IMHO, it /would/ be nice if the next CL were to make EQ on
numbers and characters a type error in safe code.)
On Feb 11, 5:07 am, Marcus Breiing <······@2009w06.mail.breiing.com>
wrote:
> * Pascal J. Bourguignon
>
> > Remember, numbers are equivalence classes.
>
> Sure, just choose your numbers and equivalence relation. Meanwhile,
> (EQL 2 2.0) still returns NIL...
>
> (Yet, IMHO, it /would/ be nice if the next CL were to make EQ on
> numbers and characters a type error in safe code.)
That would force implementations to create a pseudo EQ function (one
which doesn't error) for those situations where the implementation
itself knows that (EQL a b) ==> (EQ a b) e.g., those cases where a and
b are identical characters or fixnums. This in turn would set a
dangerous precedent for other equality operators. For example, should
EQUAL error on comparing two vectors? After all, the programmer
obviously meant to be using EQUALP to compare those vectors, didn't
he?
Duane
On 2009-02-10, pereges <·······@gmail.com> wrote:
> Can some one please show me an example of this case ? (x and y can be
> sustituted)
There is one degenerate case when (eql x y) is true, but (equal x y) is
indeterminate: it fails to produce an answer.
You see, for conses, EQUAL is defined in a trivial, recursive way, which isn't
required to detect cycles in the structure.
If x and y are the same cons, then they are EQL, but if that cons is embroiled
in a circular structure, then EQUAL may encounter infinite recursion.
But that, of course, is quite different from returning NIL!
But blowing up the stack with runaway recursion triggers undefined behavior,
and that could by fluke translate to a NIL return.
So (equal x y) could return NIL for x y that are EQL, due to pathological,
immplementation-specific circumstances that do not amount to an ANSI CL
non-conformance.
> What exactly is the difference between eql and equal ?
The difference consists of all of that which the Common Lisp Hyperspec writes
about one function, but not the other, and vice versa.
Is there a way you'd like this question to be answered that doesn't involve
cutting and pasting reams of text from the free, online, hyper-linked
specification of the language?
On Feb 10, 6:43 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2009-02-10, pereges <·······@gmail.com> wrote:
>
> > Can some one please show me an example of this case ? (x and y can be
> > sustituted)
>
> There is one degenerate case when (eql x y) is true, but (equal x y) is
> indeterminate: it fails to produce an answer.
>
> You see, for conses, EQUAL is defined in a trivial, recursive way, which isn't
> required to detect cycles in the structure.
>
> If x and y are the same cons, then they are EQL, but if that cons is embroiled
> in a circular structure, then EQUAL may encounter infinite recursion.
I suppose an implementation _may_ do that, but I find that highly
unlikely. I'd imagine that all implementations define each as a subset
of the other:
(defun eql (a b) (or (eq a b) ...))
(defun equal (a b) (or (eql a b) ...))
(defun equalp (a b) (or (equal a b) ...))
And then no such possibility for infinite recursion when comparing the
same two lists exists.
Jeff M.