Marc Nieper-Wißkirchen wrote:

> I think the notions type and subtype as used by SRFI 137 are understood by
> SRFI 137 as follows:
>
> A _type_ is a subset of all possible Scheme values. Thus each
> boolean-valued pure procedure of one argument defines a type, namely the
> type of those values for which the procedure returns true. A _subtype_ of a
> type T is a subset of the subset of Scheme values defined by T.

That's a types-as-sets definition, which is pretty different from
the notion of subtype provided by (rnrs records), (srfi 99), and
(srfi 131).  Consider, for example, the opening sentences of the
current Wikipedia article on subtyping:

    In programming language theory, subtyping (also subtype
    polymorphism or inclusion polymorphism) is a form of type
    polymorphism in which a subtype is a datatype that is related
    to another datatype (the supertype) by some notion of
    substitutability, meaning that program elements, typically
    subroutines or functions, written to operate on elements of
    the supertype can also operate on elements of the subtype.
    If S is a subtype of T, the subtyping relation is often
    written S <: T, to mean that any term of type S can be safely
    used in a context where a term of type T is expected. The
    precise semantics of subtyping crucially depends on the
    particulars of what "safely used in a context where" means
    in a given programming language.

With SRFI 137, there are hardly any contexts in which arbitrary
values of the subtype can safely be used where values of the
supertype are expected.

See also the third and fourth paragraphs of that Wikipedia article.

> > 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
>
> As soon as my time permits, I am going to complete my implementation of
> SRFI 131 on top of SRFI 136 that proves that exactly this is possible.

Then I have misunderstood something.  I will await your implementation.

> I don't see the value of "prior art" by itself if it is incompatible to the
> current version of R7RS-small (as seen by some, without the erratum that
> field names are symbols).

Although R7RS (small) is the most recent quasi-standard, it may
not be the last, and there are earlier quasi-standards whose
value is attested by the number of libraries and programs that
rely upon them.  As of this writing, I very much doubt whether
the volume of code that relies upon R7RS define-record-type
exceeds the volume of code that relies upon SRFI 9, R6RS records,
or SRFI 99.  I am quite certain that the volume of code that
depends upon interpretations of R7RS define-record-type that
are incompatible with the field names as symbols semantics is
far smaller than the volume of code that relies upon prior art.

Will