Am Sa., 19. Juni 2021 um 22:34 Uhr schrieb Wolfgang Corcoran-Mathe < [email protected]>:
> 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 < > > [email protected]>: > > > > > 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. > That's true. If you want the sample implementation maximally portable (and with respect to all corner cases like opaqueness and sealedness), you have to choose the weaker specialization. This doesn't necessarily mean that it would be a good idea, though. Actually, whatever the original wording "form a new type as if created by define-record-type" is supposed to mean, it probably cannot be implemented fully portable as well because a sample implementation cannot guarantee some kind of type disjointness if wants to be portable to Schemes that have non-standard extensions. You will only be able to write a portable R6RS and a portable R7RS implementation. But this is also true with my proposal (because either you view R7RS's record types as being sealed and opaque or you can say that this part of the language does not apply). 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. Leaving out an attribute can also mean the opposite. > 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'. > If you drop sealed, child record types can be created with a different uid but whose predicates are no longer disjoint. I could, for example, be silly and create the SRFI 146 mappings type as a child type of the fxmapping type. Then mapping? and fxmapping? won't be disjoint anymore. PS Maybe it makes sense to continue this in IRC in order not to flood the mailing lists? (Just in case you like to discuss this further.)
