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:
>
>   > (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

Reply via email to