Am Sa., 19. Juni 2021 um 19:09 Uhr schrieb Wolfgang Corcoran-Mathe < [email protected]>:
> On 2021-06-19 12:02 +0200, Marc Nieper-Wißkirchen wrote: > > "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 agree that this is a little confusing. Since the new draft hasn't > been pulled yet, I'll split out the R6RS-specific semantics as a > separate paragraph. Re: Marc Feeley's comments, I'm also not > convinced that 'sealed' is the right choice here. > Can you give some compelling use case for a non-sealed type that would promote good coding practices? > I'm not in favor of just requiring R6RS record semantics here. The > notion of a disjoint type seems to work well enough in R5+ and R7, > and there are not, as far as I know, any other SRFIs which explicitly > use R6 record semantics instead. So I'd like the original text to > stay. > The disjoint type semantics are just meaningless. Some SRFI has to start getting it right. Note that we are not requiring R6RS semantics here. We are requiring exactly the semantics we want using the language of R6RS (because there no better is existing at the moment).
