Am Sa., 19. Juni 2021 um 20:09 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>:
On 2021-06-19 19:18 +0200, Marc Nieper-Wißkirchen wrote:
> Am Sa., 19. Juni 2021 um 19:09 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
>
> > 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 think that "good coding practices" here is a bit of a weasel-phrase.

Replace it with "mathematically sound" if you want.
 
Many Schemes provide record-type inheritance, of course, and it's not
my intention to forbid extending fxmappings or any other type.
Similarly for inspection, which is completely orthogonal to SRFI 224's
goals and thus should not be disallowed.

In R[67]RS, I cannot create subtypes of the pair type, nor can I inspect instances of port types. This does not mean or forbids, however, that a particular implementation provides non-standard means to create child types of the pair type or to inspect ports.

It is exactly the same here: 'Opaque' means (among other things) that the (R6RS) 'record?' predicate won't detect fxmappings as standard records. 'Sealed' means that the type cannot be extended through R6RS standard means. This does not mean that it is entirely impossible. As R7RS neither has record inspection nor opacity, all ways to inherit or inspect record types have to non-standard, anyway.

The reason why R6RS has introduced opaque record types is that it allows some abstraction that would otherwise impossible. It lets the user create types much like the base types (which aren't record types). As much as 'record?' applied to a pair or a port returns #f, we would expect it to return #f for the extended family of base types of R7RS-large, e.g. for types like sets or mappings. We don't want to leak implementation details (through standard means).

BTW, if you allow non-sealedness, the language becomes unusable again because you wouldn't guarantee disjointness to other types anymore.