I *think* I found the answer but it didn't particularly help. It seems eq?
resolves differently in different implementations of Scheme. While I accept
this, it seems a tad pointless to have something like eq? as part of the
Scheme language when it cannot resolve something as simple as whether or not
two naked strings are equal: (eq? "hello" "hello"); ==> #f (indeterminate).
I *thought* equal? was more applicable in complex boolean operations like
comparing two lists (which I believe are recursively examined by equal?
before returning a result).
I know I am far from qualified to determine whether or not anything in
Scheme is 'good' or not. But this just seems odd.
From DRScheme help:
Eq? is similar to eqv? except that in some cases it is capable of discerning
distinctions finer than those detectable by eqv?.
Eq? and eqv? are guaranteed to have the same behavior on symbols, booleans,
the empty list, pairs, procedures, and non-empty strings and vectors. Eq?'s
behavior on numbers and characters is implementation-dependent, but it will
always return either true or false, and will return true only when eqv?
would also return true. Eq? may also behave differently from eqv? on empty
vectors and empty strings.
(eq? 'a 'a) ===> #t
(eq? '(a) '(a)) ===> unspecified
(eq? (list 'a) (list 'a)) ===> #f
(eq? "a" "a") ===> unspecified
(eq? "" "") ===> unspecified
(eq? '() '()) ===> #t
(eq? 2 2) ===> unspecified
(eq? #\A #\A) ===> unspecified
(eq? car car) ===> #t
(let ((n (+ 2 3)))
(eq? n n)) ===> unspecified
(let ((x '(a)))
(eq? x x)) ===> #t
(let ((x '#()))
(eq? x x)) ===> #t
(let ((p (lambda (x) x)))
(eq? p p)) ===> #t
Rationale: It will usually be possible to implement eq? much more
efficiently than eqv?, for example, as a simple pointer comparison instead
of as some more complicated operation. One reason is that it may not be
possible to compute eqv? of two numbers in constant time, whereas eq?
implemented as pointer comparison will always finish in constant time. Eq?
may be used like eqv? in applications using procedures to implement objects
with state since it obeys the same constraints as eqv?.
library procedure: (equal? obj1 obj2)
Equal? recursively compares the contents of pairs, vectors, and strings,
applying eqv? on other objects such as numbers and symbols. A rule of thumb
is that objects are generally equal? if they print the same. Equal? may fail
to terminate if its arguments are circular data structures.
@bigpond.net.au> wrote in message
> So I just tried the obvious to see if I had made a typo: Take the following with a (small) grain of salt:
> (eq? "hello" (car '("hello"))) ;==> #f
> Is my machine broken? I *thought* eq? compared two string objects to see if
> they were equal and returned a boolean value #t if they were and #f if not.
Two strings are eq? if the strings are located at the same memory
That is "hello" and "hello" are eq? if they happen to refer to the
same exact same place.
Examples from DrScheme:
> (define a "foo")
> (define b a)
> (eq? a b)
If the strings are located in different positions, they are not eq?
> (define c "bar")
> (define d "bar")
> (eq? c d)
The interesting part is the last. Some Scheme implementations
recognize in (define d "bar") that it has seen "bar" before,
and thus reuse the same string, it used for c. Thus some
implementations will answer #t to the last example.
To find out whether the contents of two strings are the same
use either string=? or equal?. (If you know that you are
comparing strings, use string=? to make it clear).
Jens Axel Sgaard
Thanks for that - makes perfect sense.
The strings "foo" and "foo" exist in different memory addresses. I'm
assuming this is reasonable because with a slew of such strings in a
procedure, I could consume all available memory eventually - each string
exists in different memory addresses. eq? must be looking at the contents
of a single memory address (pointer??). I think I will stick with equal? -
more robust and I don't need to test for type to determine which form of
equality test to use (I think).
"Jens Axel Sgaard" <email@example.com> wrote in message