[R6RS] R6RS records: record equality

[Marc Feeley]

On 26-Aug-05, at 3:04 PM, William D Clinger wrote:

> Marc wrote:
>
>> The specification indicates that two records are equal? iff they are
>> eq? (except if they represent builtin types like pairs, vectors,  
>> etc).
>> I object to the "equal? iff eq?" because it limits the use of  
>> records.
>> I would prefer a recursive definition where (equal? r1 r2) is true  
>> iff
>> r1 and r2 are of the same record type, and for each field, the  
>> contents
>> of that field in r1 and r2 are equal?.
>>
>
> I believe this would make the equal? comparison for records
> equivalent to testing the operational equivalence of finite
> automata, which I think is probably exponential in the worst
> case.  Alternatively, we could allow equal? to go into an
> infinite loop when comparing records, as it sometimes does
> when comparing pairs and vectors.
>

Yes I am advocating that on records equal? can go into an infinite loop
when there are cycles, i.e. equal? tests equality through a recursive
process (it would be awkward to require that equal? handle cycles in  
records
when it doesn't even do that for pairs and vectors).

>
>> Aside from that I don't understand the rationale for
>>
>>    (eqv? r1 r2)  not implying  (eq? r1 r2)
>>
>> What's the practical use for this?
>>
>
> This allows eq? to be implemented by a pointer comparison,
> even in systems that support unboxed representations for
> records.
>
> The performance advantages of both techniques are well known.
> Why force implementations to choose between them?
>
> Will
>

But doesn't that mean that (eqv? r1 r2) is not a pointer
comparison, and (eqv? r1 r2) is the only way to test portably
that two records are the same?  So when does it make sense
to use (eq? r1 r2) in portable code?

Marc