Am Mi., 4. Jan. 2023 um 21:41 Uhr schrieb Jim Rees <jimree...@gmail.com>: > > On Wed, Jan 4, 2023 at 1:41 PM Marc Nieper-Wißkirchen <marc.nie...@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. :)
