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.
Marc Nieper-Wißkirchen wrote:
> While they provide unique types, neither SRFI-9 nor R7RS-small
> records provide subtypes.
SRFI 137 doesn't provide subtypes either. It just uses the
word "subtype" in a misleading way.
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.
In fact, it does not make much sense to say that a type is disjoint from all other types because only the empty type fulfills this condition. Thus indeed, "all existing Scheme types" has to be clarified.
> More sophisticated record systems like SRFI 131 or SRFI 136
> provide subtypes. When the underlying implementations differ,
> however, it may not be possible to intertwine, say, SRFI 131,
> SRFI 136, and (rnrs records) in inheritance chains of subtypes.
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. It will be part of the next draft of SRFI 136 (and does not use SRFI 137). To be honest I don't understand the point why it shouldn't be possible? To make it possible is one of the reasons for the procedural interface in SRFI 136.
We have prior art in which inheritance chains of record subtypes
can mix record types defined using (srfi 9), (rnrs records),
(srfi 99), (srfi 131), and (scheme base). The only problem with
that is a recent claim that records defined by (scheme base) are
not intended to be compatible with record systems in which field
names are symbols. Implementations can ameliorate that problem
(without resolving it for portable code) by ignoring that recent
claim.
I don't understand your point. If WG 1 and the main implementations agree on field names as symbols in (scheme base) records (which could be expressed by erratum to R7RS-small), SRFI 99/SRFI 131 works well and there is no problem.
However, if WG 1 and implementations cannot agree on this point, only two possibilities are left: either refer in the constructor to fields by position (as in SRFI 136 or (rnrs records)) or refer to fields in the constructor by accessor-name. (The latter will probably make it impossible to implement the syntactic layer on the procedural layer.)
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).
What I am missing is: What feature does SRFI 131 provide that a positional system like SRFI 136 cannot provide, and which is so important, so that it is persuading reason to amend R7RS even to those who have been against amending R7RS that field names are symbols?
Marc