Am Mi., 4. Jan. 2023 um 21:41 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:
>
> On Wed, Jan 4, 2023 at 1:41 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>>
>> My idea was that this guarantees the most for the user of SRFI 226
>> because equal? is the coarsest standard equivalence predicate.  This
>> is what Racket does as well, so there is a compatibility argument.
>
>
> Ok I don't want to discount the potential value of this.  I can imagine scenarios where this might be useful.   Say if the representation of a tag was (tag 42), then the user doing debugging could simply type this in.
>
>>
>> Even in an R6RS implementation where records are compared using eqv?,
>> an extra internal field may be necessary because an R6RS
>> implementation is allowed to treat two records with only immutable
>> fields the same if they are field-wise the same.
>
>
> Are you sure?  The rules at http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-7.html#node_sec_6.1 seem to make it clear that distinct record constructor calls yield records that are not eqv?.  I do not see an exception for the all-immutable field case.   I see some discussion threads where some felt this would be desirable though.

It's in the errata, § 6.1 of the Standard Libraries:
http://www.r6rs.org/r6rs-errata.html.

> Requiring equal? does not make implementing the SRFI any harder, but it makes passing tests which test this requirement just a wee more difficult on systems where equal? dives into records.
>
> But I don't want to stand in the way of doing "the right thing" if there's merit to sticking with equal? for consistency and compatibility.

I will give it one more thought. :)