I accidentally replied the following to just Arthur, but meant to send it to a wider audience:

     I've said it before, and I'll said it again: Having all these distinct datatypes
     with distinct APIs and no subtyping is bonkers.

     Nothing against this particular SRFI, which is just another
     example of a bad approach to design a language.   Common Lisp did this
     much better in 1984.

Arthur agreed that "we should [probably] have a subtyping mechanism",
and encouraged proposals along these lines.  However, there is no point
unless these are a significant number of users and implementors who feel the same.

This means not just designing an API for defining types and classes,
but also re-thinking and slimming down SRFI 214 and a dozen collection
APIs to make use of sub-typing.

I believe there is no point in continuing with r7rs-large on its current course
without sub-typing; I think it is doomed to sink under its own weight.

FWIW, Kawa's define-class/define-simple-class has the necessary functionality,
but the syntax (based on Common Lisp) may not be to everyone's liking,
and it has more tweaks and features than makes sense for a standard:
https://www.gnu.org/software/kawa/Defining-new-classes.html

What is needed IMO is a way to define "types" (interfaces)
with multiple inheritance of methods (with optional default implementation),
and no fields; and concrete "classes" that implement interfaces,
have fields, and (probably) no inheritance.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/