Am So., 13. Juni 2021 um 20:58 Uhr schrieb Wolfgang Corcoran-Mathe <
[email protected]>:

> On 2021-06-13 11:06 +0200, Marc Nieper-Wißkirchen wrote:
> > Luckily, there is a solution, which can be implemented right now and
> which
> > is future-proof, namely using uids, through which we can exactly express
> > what we want.
> >
> > So the above sentence cited from SRFI 224 would become:
> >
> > "Fxmappings are instances of a sealed, opaque, nongenerative record type
> > with uid
> > fxmapping-2bf340e5-304e-436e-8478-926c7040f3f."
> >
> > Later SRFIs would use similar uids (prefixing a UUID-4 with the type
> name),
> > earlier SRFIs will have to be revised anyway.
>
> How does associating a type with a unique string guarantee its
> disjointness in Scheme's type system?  Unless a future standard
> incorporates something about types with different UUIDs being
> disjoint into its semantics, I don't see how this is any more
> meaningful than the current advisory statements.  It seems a
> little like associating booleans with the Empire State Building
> and vectors with the Chrysler Building; sure, those are unique
> things, but what does it say about Scheme?
>

R6RS §11.1. Base types: "No object satisfies more than one of the following
predicates: ..."
R6RS Standard Libraries §6. Records: "Records of different types can be
distinguished from each other and from other types of objects by record
predicates."
R6RS Standard Libraries §6.2. Syntactic layer: [Description of the
nongenerative clause.]
R6RS Standard Libraries §6.3. Procedural layer: "Two nongenerative
record-type descriptors are eqv? iff they were created by calls to
make-record-type-descriptor with the same uid arguments."

PS: As the R7RS base language is not rich enough, I have to cite R6RS here,
but the semantics can be applied mutatis mutandis to R7RS as well (as we
are talking about opaque and sealed record types).

Reply via email to