Am So., 13. Juni 2021 um 22:52 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Sun, Jun 13, 2021 at 5:06 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
 
At some point, we should start getting it right, and the current SRFI 224 can be such a starting point. SRFI 224 uses one of the many variations of flawed attempts to deliver the intended meaning. It says: "Fxmappings [...] form a new type, as if created by define-record-type (see R7RS § 5.5). The effects of using record-type inspection or inheritance for the fxmapping type are unspecified."

I like this wording very much, actually.

I liked it when I was younger (when did I write SRFI 146?).
 
(An analogous more or less meaningless sentence is in SRFI 146 authored by me.)

The usual reply to arguments that the current wordings are, at best, meaningless

Lack of rigor is not the same as lack of meaning, unless you are Carnap.

It may not in a non-normative section of a SRFI. For the actual specification, we should do better as we can. That it is meaningless as part of the specification was already observed early by Will Clinger.

"Fxmappings are instances of a sealed, opaque, nongenerative record type with uid
fxmapping-2bf340e5-304e-436e-8478-926c7040f3f."

Quite apart from non-generative records being absent from R7RS-small, this would mean that if there are multiple implementations they must all share the same uid, which is very problematic.

The first object is minor as most SRFIs are quite vague about the standard on which they build. In the case of R7RS-small, it is enough to assume the behavior as if it had an equally rich record facility as R6RS.

For the latter, what you seem to perceive as a problem, is actually one of the main benefits of the proposal because it is a direct mapping from the meaning. If two there are two implementations of, say, mappings, loaded into one system, we want an error to be raised if they are not compatible. This is exactly what nongenerative record types are about.
 
 A side benefit of this proposal is that it begins to pave the way to the serializability of non-core types.

I don't believe in Java-style serialization of compound types anyway.  Types should be serialized in a way that reflects their interface, not their implementation.

You still need to preserve the type identity and this is where you need uids. You cannot distinguish two record type instances of the same shape just by the interfaces they implement.