Re: [Scheme-reports] eq? and eqv? for records

[taylanbayirli@x (Taylan Ulrich Bayırlı/Kammer)]

John Cowan <cowan@x> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> The `eqv?' definition says that records are equivalent if denoting
>> the same location and points to section 3.4, which explains that the
>> notion of "storage being newly allocated" is what denotes the
>> creation of objects with distinct locations, yet section 5.5
>> (<constructor name> point) doesn't use that phrase.  In short, we
>> base record equivalence semantics on their location, yet don't
>> specify their location.
>
> But 5.5 does say that each field of a record is a location.  True, it
> doesn't say a _distinct_ location, but I think that can be safely
> inferred.  From that, it follows that records of a non-empty type are
> different in the sense of `eqv?` iff they are created by distinct
> constructor invocations.  A fortiori, they are distinct in the sense
> of `eq?` as well.  The standard leaves open what happens when
> comparing records of the same empty type.
>
> Note that this argument is quite independent of whether the fields
> have mutators or not: they are still locations per 5.5.

Interesting, so far I've been interpreting `eqv?' to mean that it
returns #true when two objects *themselves* denote the same location (or
rather, reside at the same location).  (Regarding strings, vectors,
etc., that is.)  I see that was wrong, and it refers to the collection
of locations denoted by the object.  So for instance there's nothing
keeping an implementation from having an indistinguishable copy of a
mutable object, residing at a different location but denoting all the
same locations.

Anyway, this doesn't actually make a difference to my point, since it's
still the same semantics that apply to records as well as other
location-denoting types.  All other types that denote collections of
locations use the phrase "newly allocated" (which is specifically
defined for this purpose at the start of section 6) so there's no reason
to special-case record types.

If anything, we should special case them to mention that immutable
records might share structure even when returned from distinct calls to
a constructor, akin to how literals can share structure because they're
immutable.

Taylan

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports