Am Sa., 19. Juni 2021 um 19:49 Uhr schrieb Wolfgang Corcoran-Mathe < [email protected]>:
> On 2021-06-19 14:46 +0200, Marc Nieper-Wißkirchen wrote: > > Am Sa., 19. Juni 2021 um 14:30 Uhr schrieb Marc Feeley < > > [email protected]>: > > > > > > On Jun 19, 2021, at 6:02 AM, Marc Nieper-Wißkirchen < > > > [email protected]> wrote: > > > > > > > > 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." > > > > > > > > > > This wording does not work for Schemes with single inheritance record > > > types, which are a fairly simple (and very useful) extension of record > > > types. For example in Gambit you can define the record type bar as a > > > subtype of the foo type like this: > > > > > > [snip] > > > > It is really the question of what one wants (and we don't even have to > look > > at a specific implementation like Gambit because your example works > mutatis > > mutandis in R6RS). > > > > The usual wording in similar SRFIs has been something along the lines of > > "... belong to a new type disjoint from all other types ...". When we try > > to make sense of it, we can interpret this as that we don't want to allow > > inheritance here because this would create non-disjoint types. This is > why > > the attribute "sealed" appears in my proposed wording, meaning that it is > > an error to create subtypes through inheritance. > > This convinces me that neither 'sealed' nor 'opaque' should appear in > the 224 spec. Extension and inspection are unspecified, not forbidden. > If you want extension and inspection unspecified, you mustn't leave out 'sealed' and 'opaque' because this would mean that inspection and extension are possible (and that the type is actually a record type). What you must do then is to say that it is unspecified whether the record type is 'sealed' and/or 'opaque'. I still don't think that it is reasonable. The procedures in SRFI 224 are not generic over extension types of fxmappings. If you apply a procedure like 'fxmapping-adjoin' on an instance of a child type, you generally will only get back an instance of the base type. This is why I asked you in a previous post whether you have any compelling code examples where the code does not do something dubious or mathematically unsound.
