On 2021-06-19 20:23 +0200, Marc Nieper-Wißkirchen wrote:
> Am Sa., 19. Juni 2021 um 20:09 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
>
> > 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.
>
> 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.

As such, I can't see that there's any standard non-R6RS way to ensure
that a type created (as if) by define-record-type is 'opaque' or
'sealed'.  The sample implementation, e.g., can't ensure that
`(record? some-fxmapping)` is #f in a Scheme implementation providing
such a predicate, or that fxmappings are otherwise disjoint from some
record supertype.

Opaqueness and sealedness are good features that I like and would
use, but I would not want to force them on people.  Hence they are
(implicitly) optional.

That which we do not specify is unspecified.

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

Maybe I've misunderstood, but I think that we have a disconnect between
what R[57]-flavored SRFIs mean by "disjoint" and what is entailed by
the semantics of 'sealed'.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"The Algol compiler was so poorly implemented that we dared not rely
on it, and working with assembler code was considered dishonorable.
There remained only Fortran." --Niklaus Wirth