PS I just read the relevant new paragraph in your latest personal draft: "Fxmappings (pronounced "fix-mappings") form a new type, as if created by define-record-type (see R7RS § 5.5). In systems supporting R6RS record-type semantics, fxmappings are instances of a sealed, opaque, nongenerative record type with uid fxmapping-7a1f4d5b-a540-462b-82b1-47283c935b85. The effects of using record-type inspection or inheritance for the fxmapping type are unspecified."
The first sentence remains meaningless, the semantic implications of the second should also hold for R7RS schemes, and the final sentence sounds superfluous at best as the sentence before that talks about a sealed and opaque record type. I have been thinking of a formulation as the following one: "Fxmappings are instances of a sealed, opaque, nongenerative record type with uid fxmapping-7a1f4d5b-a540-462b-82b1-47283c935b85 where the semantics shall be as specified by R6RS, Library Chapter 6. In particular, this means that the type defined by the record type predicate `fxmapping?' is disjoint from the base types defined in R6RS and R7RS and from any generative record type and any non-generative record type with a different uid." Marc Am Fr., 18. Juni 2021 um 22:43 Uhr schrieb Marc Nieper-Wißkirchen < [email protected]>: > Am Fr., 18. Juni 2021 um 22:33 Uhr schrieb Wolfgang Corcoran-Mathe < > [email protected]>: > >> On 2021-06-15 22:52 +0200, Marc Nieper-Wißkirchen wrote: >> > For R6RS implementations of fxmappings, the UID as specified in the SRFI >> > could be used (which would be no problem because the UID would be >> > well-known). In principle, a specific implementation could choose some >> > other, arbitrary UID (unique in the sense that it does not clash with >> any >> > other assigned UID, e.g. a UUID-4) or even a generative record >> definition, >> > but I don't see any advantage in doing so, only the disadvantage that >> the >> > Scheme system then wouldn't be able to warn you if you tried to load two >> > different implementations of fxmappings into the same running Scheme >> system. >> >> If it's useful for systems that have R6RS records or something >> similar, then I'm glad to add it. I can't see how it could cause >> problems for other implementations, in any case. >> > > NB: While it can be of use for R6RS systems, this wasn't my main > motivation to refer to the R6RS semantics. I mainly did because it provides > exactly the semantics we have been trying to express and because it is > already specified, so it can be added to future (and retroactively to > earlier) SRFIs without any dependencies (besides Scheme semantics published > in official standards). > >
