[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

EQ? Survey Entry

1. (EQ?  (LAMBDA (X) X) (LAMBDA (Y) Y))		;"Coalescing"      ==> I
2. (EQV? (LAMBDA (X) X) (LAMBDA (Y) Y))                            ==> I
3. (LET ((X (LAMBDA (Z) Z))) (EQ?  X X))	;"Splitting"       ==> I
4. (LET ((X (LAMBDA (Z) Z))) (EQV? X X))                           ==> I
5. (LET ((X ... any expression evaluating to an exact number ...)) ==> I
     (EQ? X X))
6. (EQ? #\X #\X)						   ==> I

My position is quite simple: EQ (EQ?) has historically been
implementation-dependent and is the wrong function to be associated
with any kind of formal ``identity'' predicate.  Let's define EQ? to
be a predicate on representations, not abstract types, and let's
decide which representational identities we're going to require of a
conforming implementation.

The reason I want such an EQ? is two-fold: (1) We need an identity
predicate for symbols, and (2) we need to know when we have the same
*instance* of a mutable object so we know which one we are modifying.
Thus, I suggest that EQ? be defined only for symbols, booleans, (),
and mutable objects (pairs, vectors, strings, and ports).  It should
be undefined (implementation-dependent but not an error) for numbers,
characters, closures, and continuations.

Thus (EQ? X X) is not necessarily #!TRUE unless X is appropriately
typed.  I believe this position is consistent with Will's.

I agree with Jonathan that EQV? should also be defined over an
incomplete domain.  I'd like to see it extend EQ? to encompass exact
numbers and characters but not closures and continuations.

EQUAL? should be like EQV?, but also knows how to descend into
subcomponents of pairs and vectors.  Again, it should not be defined
for closures and continuations.

Perhaps we should define an EQL? if someone really wants a predicate
that somehow tries to do the ``right thing'' for closures and
continuations, but I don't have any need for it.

David Bartley