> Maybe one should say that this SRFI is a minimal extension to R7RS-small
> that provides *unique* and *subtypeable* types.
So does this mean the SRFI meant to be a part of R7RS-large?

> While they provide unique types, neither SRFI-9 nor R7RS-small records
> provide subtypes.
Like I said, you can implement more sophisticated record systems on top of
them.

> 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.
> If all implementations of record-type systems agree on using SRFI 137 for
> creating and subtyping types, they will at least be compatible in this
> regard.
IMO, this SRFI takes away some freedom from implementations (not record type).
For example, Sagittarius, which supports both R6RS and R7RS, uses own object
system to implement both R6RS and R7RS-small (the same as SRFI-9) record
systems. But if this SRFI (well, hoping not but) mandates to be underlying
type system of all record systems and (again hoping not) will be a part of
R7RS-large, then implementations can not choose to use own object system for
R7RS.

Moreover, this SRFI looks rather adhoc to me, because:

1. It can not be a base of whole Scheme types (correct me if I'm wrong)
2. There's no way to retrieve parent payload value by parent accessor.
   To me, this is rather weird/broken type system.
   (again correct me if I'm missing something)
3. It seems this SRFI is created because SRFI-136 can't be implemented
   without keeping compatibility of other record types.

Cheers,

--
_/_/
Takashi Kato
E-mail: ktakashi19@gmail.com