William D Clinger scripsit:

> Does that mean the sample implementation would be illegal in
> implementations where records created by define-record-type are
> recognized by the record? predicate of (rnrs records) or (srfi 99) as
> belonging to the type consisting of all records?

I don't see how.

> Scheme has no official notion of type, so "a type that is disjoint
> from any existing Scheme type" is meaningless without further
> explication.  The sentence quoted above should be replaced by
> something along the lines of the following sentence of SRFI 9:
> "Records are disjoint from the types listed in Section 4.2 of R5RS."

Quite so.  Unfortunately, we are in a chicken and egg position at
present.  The types of Scheme have been stable since R2RS, but things
will change in R7RS-large.  For example, if SRFI 113 sets are adopted,
then `set?` will be a type predicate of Scheme.  It would be absurd to
create a situation in which objects returned by a SRFI 137 constructor
were guaranteed to answer `#f` to `symbol?`, but might answer either
`#t` or `#f` to `set?`.  We won't be able to make a new enumeration of
Scheme's types until R7RS-large is complete, or at least until it is
much further along than it is today.  So I'm basically stuck with using
vague language which will all come together in the Ultra-Violet Edition.

> As has been mentioned by others already, this SRFI's notion of
> subtyping affects only the predicates returned by the make-type and
> make-subtype procedures, and bears no relationship to the Liskov
> substitution principle.

Again, quite so, though it does not prevent users of the type system
from applying it.  The LSP is formally undecidable, and I think of it
as a principle for designing specific type relationships rather than a
precondition enforced by a type system.

> SRFI 137 doesn't provide subtypes either.  It just uses the word
> "subtype" in a misleading way.

Misleadingness is in the eye of the beholder.  SRFI 137 guarantees that
the set of objects answering true to a subtype is a subset of those
answering true to any supertype.  Relationships between payloads must be
enforced by the user of SRFI 137.

> The reason it is not possible to create chains of record subtypes
> that include record types defined by both SRFI 131 and SRFI 136
> is simple: SRFI 131 matches field names by name as though they
> were symbols, while SRFI 136 uses positional matching.  That
> incompatibility cannot be removed by cleverness of implementation,
> and that incompatibility is not ameliorated by SRFI 137.  Adding
> yet another incompatible notion of subtypes does not improve the
> situation.

Every system beyond SRFI 9 aka R7RS-small that I know of requires and
guarantees the above subset relationship, and therefore can be built on
SRFI 137.  What is more, SRFI 137 can be built on top of any of them,
provided they have some run-time extension.  I agree that this does not
magically make incompatible record systems compatible.

SRFI 137 is analogous to universal file systems like the Cambridge
File System, which provide a mapping from file UIDs to byte arrays,
one or more indexes to preserve UIDs in, and a guarantee that a file
will be preserved iff its UID is stored in some index reachable from the
root index.  Multiple naming and file-metadata systems can be built on
top of this: the CFS merely allows them to share the same disks without
colliding -- it provides no automatic user-level interoperability.

> WG2 has the power to resolve that situation or to make it worse.
> We'll see.

But not today.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Values of beeta will give rise to dom!
(5th/6th edition 'mv' said this if you tried to rename '.' or
'..' entries; see http://9p.io/who/dmr/odd.html)