Am So., 13. Juni 2021 um 23:38 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Sun, Jun 13, 2021 at 5:17 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Lack of rigor is not the same as lack of meaning, unless you are Carnap.

It may not in a non-normative section of a SRFI. For the actual specification, we should do better as we can. That it is meaningless as part of the specification was already observed early by Will Clinger.

I think he was objecting to the "disjoint type" wording: disjoint from what?  But I don't know exactly where he said that.

I don't have a reference at the moment. It was about meaningful wording. "Disjoint type" was ruled out.

Anyway, the wording I chose for SRFI 146 and which is also in SRFI 224 doesn't imply what it intends to imply.
 
"Fxmappings are instances of a sealed, opaque, nongenerative record type with uid
fxmapping-2bf340e5-304e-436e-8478-926c7040f3f."

I left out another objection: fxmappings might not be implemented as Scheme records at all, but as objects in some lower-level language.  If they behave *as if* they were records of a disjoint type, that is all a standards writer can ask.

I'm glad that you come up with this (easily to defeat) objection because it illustrates the proposal.

The keyword here is "opaque". The raison d'être for sealed record types (as one can read in the mail archives from the R6RS process) is that every Scheme object (including those of core types like pairs) can be modeled with them. Being sealed makes being an instance of a record type an unobservable implementation detail.
 
For the latter, what you seem to perceive as a problem, is actually one of the main benefits of the proposal because it is a direct mapping from the meaning. If two there are two implementations of, say, mappings, loaded into one system, we want an error to be raised if they are not compatible. This is exactly what nongenerative record types are about.

If they have the same interface (which is what a SRFI prescribes), why can't they have completely different representations even in the same system?

If the implementations of the two different representations are related, the requirement of my proposal is easily achievable. And if they are not, mapping-ref, say, coming from one implementation applied to a mapping instance of the other implementation would break in any case.
 
You still need to preserve the type identity and this is where you need uids. You cannot distinguish two record type instances of the same shape just by the interfaces they implement.

If I wish to serialize and transmit a fxmapping, what I want is that the other end reconstitutes it as a mapping from small integers to arbitrary objects, without excluding that it might be represented by a quite different data structure.  In particular, it might be represented by a dictionary in Python.  This is good, not bad.

This is good, yes, but a very different use case. I have been talking about situations where you need to preserve object identity. The default Scheme reader and writer preserves this (and this includes type identity). A written list is not read back as a vector (although both can represent a sequence). If the Scheme reader is extended to record types, uids will play a role. Of course, this is not the only sensible way to serialize and transmit objects. Different use cases need different strategies.