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

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

On Thu, Feb 13, 2014 at 10:14 PM, Taylan Ulrich Bayırlı/Kammer <taylanbayirli@x> wrote:
Sascha Ziemann <ceving@x> writes:

> On page 31 of R7RS draft 9 it is written:
> "On symbols, booleans, the empty list, pairs, non-empty
> strings, vectors, bytevectors, and records, eq? and eqv? are
> guaranteed to have the same behavior."
> And later on the same page:
> "On empty strings, vectors, bytevectors, and records, eq? may
> also behave differently from eqv?."
> Have eq? and eqv? the same behaviour for records or do they behave
> differently?
> The first sentence could also mean that eq? does the same for strings
> and records. But what is the record equivalent for an empty string?
> Does it exist?

I believe an empty record would be one without any fields:

(define-record-type <token>
  (make-token) token?)


Hrm, at first thought I would expect this to work for creating unique
objects that can be compared with `eq?' to test identity, the same way
`cons' (or `gensym' if available) is often used.

`gensym's have names, so they would not be empty.

For the tokens you create above, it really doesn't matter
if you substitute one for the other.  Given that there is
no other way in the language to tell them apart, it doesn't
make sense to require `eqv?' to do so, at the expense of
potential optimizations.

To be pedantically conformant to that viewpoint (though I know it
doesn't necessarily try to), R7RS-small should also allow immutable
records with identical contents to be `eq?' (and `eqv?'), and not
prescribe a #false return-value when testing their equivalence.  (All
other "container" data types have no way to be immutable other than
being literals, or empty, if I'm not mistaken, so this issue only
applies to record-types, since they can be defined to be immutable by
omitting mutators.)

Many people want different extensions to records,
notably the ability to create opaque and/or immutable
records, as well as inheritance, etc.  We left both such
extensions and `equal?' semantics on records up to
the large language, and so were conservative in what
we specified in the small language for `eqv?'.


Scheme-reports mailing list