Am Mi., 2. Nov. 2022 um 11:28 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> On 2 Nov 2022, at 11:18, Marc Feeley (via srfi-237 list) <xxxxxx@srfi.schemers.org> wrote:
>
> > I think this (the “must” detect the redefinition) would be too big of a burden on the implementation.  It is not even clear what scope the registry must have (I would think it needs to be at the same level as a library registry because some other programmer may be redefinining the record type with no prior compilation of the original record type).
>
> It also prevents two distinct libraries from internally using two different implementations of the same record (i.e. data structure) within the same program, even if those implementations never directly interact.

I don't understand this.  If there is no interaction, just give the
two record types different UIDs (or let the syntactic layer create one
for you).

> > In any case, there is a simpler approach, namely to create a hash of the relevant parts of the record definition and to combine this hash with the UID.  That way, if the number of fields, the name of the fields, the UID, etc change then the type will effectively be a different type.
>
> I think this makes more sense than having a UID at all, but I’ve given up arguing against the design decisions in the R6RS record library.

A record type is more than the sum of its fields.  Think of a point in
a plane represented by cartesian or polar coordinates.  Both record
types would be of the same shape (same hash under the assumption the
field names are the same), but they represent different things.  So,
in general, the hash should be preceded by a UID.