Is eqv? the portable way of checking object equality?
R5RS equality predicates: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.1
R6RS equality predicates: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.5
There are a few other differences as well, but numbers
and characters are indeed the most commonly encountered.
> I have read that as a result of this one ought to use eqv? as a
> portable means for checking for object equality unless performance is
> such an issue that eq? should be used instead.
That's reasonable, modulo the quibble with "object
> Is eqv? the portable way of checking object equality?
Yes to the first half of that sentence, provided you
replace "portable" by "most portable standard".
As for the second half of the sentence, I have this
quibble: In general, there is no such thing as *the*
notion of object equality; the appropriate notion of
object equality depends upon the context. In particular,
it depends on whether you want to compare two objects
with respect to mutability (that is, does a side
effect to one object imply the same side effect to
the other?) or with respect to their current state.
In Scheme (whether IEEE/ANSI/R5RS or R6RS), eqv? is
the most implementation-independent of the pre-defined
equivalence predicates that are defined on all objects
and are guaranteed to distinguish two distinct mutable
objects. Similarly, equal? is the pre-defined partial
equivalence predicate that distinguishes on the basis
of current state but not on the basis of mutation; the
R6RS equal? is also total.
In Scheme, eq? is basically an efficiency hack that
can be used as an alternative to eqv? when you know
for sure that at least one of the arguments is a
boolean, symbol, empty list, pair, procedure, non-empty
string, non-empty vector, non-empty bytevector (R6RS
only), or record (R6RS only). The rationale for eq?
is that it is often about ten times as fast as eqv?,
which is enough to matter for some applications, and
the specific list of situations for which eq? is
guaranteed to behave the same as eqv? is about as
inclusive as it can be without sacrificing speed in
Depending on whar kind of objects you're dealing with. I.e. (eqv? 1
1.0) is often #f.
For inexact and exact numbers, =. That is the normal way to check
Iirc it is.
I just wanted to say that eqv?/equal? do not always behave as one
expects `the portable way of checking object equality' to behave. As
for me, I was quite surprised when I first ran into in-equal?-ity of
an inexact number and its exact counterpart.