[R6RS] `eqv?' on immutable records

[William D Clinger]

Mike wrote:
> Nevertheless, we have
>
> (let ((r (C v ...)))
>   (eqv? r r)) => #t
>
> where C is a constructor for an immutable record.

The question is why we have that.

That law is one of the standard mistakes people make
when they try to describe the semantics of equivalence
procedures.  It seems like an obvious, harmless axiom,
but it doesn't accomplish anything useful by itself,
and attempts to generalize it seem inevitably to rule
out the very kinds of unboxing transformations that we
want to allow.

> I'm not sure how to
> formulate a general statement that makes this true, that won't also make
> this true:
>
> (let ((r (C v ...)))
>   (eq? r r)) => #t

Here's the kind of general statement you want:

    If x is a record and y is not, or y is a record
    and x is not, then (eqv? x y) is false.

    If x and y are both records, and one of x and y
    is mutable but the other is not, then (eqv? x y)
    is false.

    If x and y are both mutable records, then (eqv? x y)
    is true if and only if x and y denote the same
    locations in the store.

    If x and y are both immutable records, then
    (eqv? x y) may be false.  [Rationale: Either
    x and y may have been subjected to boxing and
    unboxing since they were created, and we don't
    want to burden immutable records with locations,
    serial numbers, or any other notion of object
    identity.]

    If x and y are both immutable records, and (eqv? x y)
    is true, then x and y behave the same when passed
    as arguments to any procedure that can be written
    as a finite composition of Scheme's standard
    procedures.

Note that this general statement does not guarantee
the axiom quoted at the beginning of this discussion.
Anyone who wants to complain about that is welcome
to submit their own general statement, and I will
limit my remarks to explaining why a general statement
goes too far by ruling out desirable transformations
or has the opposite problem of failing to justify
desirable transformations.  To the rabble, the axiom
quoted at the beginning of this discussion will seem
like a desirable transformation, but it is not.

> More generally, we say right now that even immutable pairs, vectors, and
> strings denote storage locations: In the light of the above, shouldn't
> we also make adjustments here to make them the same as immutable
> records?

That was a mistake that was put into the R5RS at the
insistence of the rabble.  You are certainly free to
make the same mistake in the R6RS.

Will