Am Sa., 19. Juni 2021 um 14:30 Uhr schrieb Marc Feeley <xxxxxx@iro.umontreal.ca>:
> On Jun 19, 2021, at 6:02 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> 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:

  > (define-type foo 
      extender: define-type-of-foo
      id: foo-B0C62CC8-F4E9-4C45-B28D-08372CE45BCE
      x)
  > (define-type-of-foo bar
      id: bar-C7C6C8CF-E107-4CA2-8AD4-04BF3D0804FB
      y)
  > (define a (make-foo 11))
  > (define b (make-bar 22 33))
  > a
  #<foo #2 x: 11>
  > b
  #<bar #3 x: 22 y: 33>
  > (map foo? (list a b))
  (#t #t)
  > (map bar? (list a b))
  (#f #t)

Note that they are both non-generative types, but even though they have different ids they are not disjoint (the object b is both a foo and a bar).

The practical implication of your proposed wording is that it would not be allowed to create a non-generative subtype of the fxmapping type.

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.

If we don't want to be as strict (weakening the specification), we can instead say:

"Fxmappings are instances of a 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 or any non-generative record type with a different uid that is not a child record types of the fxmapping type. It is unspecified whether the record type is sealed and/or opaque."
However, I don't think that this is a particularly good weakening because it makes reasoning about the code harder (because we have less information) and because SRFI 224 doesn't even export the identifiers (like one bound to a record type descriptor) that would be needed to actually create subtypes.

Marc