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. 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.
