> we should [probably] have a subtyping mechanism

+1 but agree with Marc that we should be careful about it and explore
options.

> 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.

+1

> 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.

Hmm. In practice, the RnRS number tower already relies on subtypes and
multi-methods internally. If there was a collection API similar to the
number API, it could easily be made to run fast even in simple
interpreters where the collection types are implemented in C.

If standard datatypes use a generic subtyping and method dispatch
mechanism baked into the language, will it be easy to make it fast?

Ideally at least the collection API will be something that can also be
used in implementations that don't bring in all of R7RS-large. And since
R7RS-small already requires specialized collection procedures for lists,
vectors, bytevectors, and strings, those should be plugged into the
generic collection API.

> 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.

No opinion on this; need to think more.