Maybe we should first answer the question *why* we want to have a
common API for all, say, sequence-like data types. There are a couple
of answers to this, some more convincing than others, but in any case,
it will depend to a not inconsiderable extent on the answers given in
which direction we will have to proceed.

For example, there is compile-time overloading and runtime
overloading. Compile-time overloading is like Java's generics or C++'s
template system. Runtime overloading is known well from classical OOP.
The C++ people have been moving from the latter to the former. The
latter is more flexible but it will probably noticeably less efficient
than the former.

That's why I think we should do some research in that area first.
Runtime-overloading (as in the many Lisp/Scheme object systems) has a
lot of examples and is somewhat well-understood. Expand-time
overloading and the exploitation of the Scheme macro system in this
regard is a more novel idea but it may lead us much farther. We can
possibly have generic algorithms that are no less efficient than
algorithms individually crafted for each type.

tl;dr No rush job, let's evaluate first and do it optimally.

Am Do., 8. Okt. 2020 um 19:32 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>
> I agree that the prefixed datatypes are a mess and that subtyping would
> help. I've been considering putting together an object system SRFI,
> likely based on one of the many CLOS-like systems in Scheme. It should
> be possible to find some broadly-compatible subset of features out of
> the many CLOS-like object systems out there, and with the right
> limitations on multiple inheritance it may even be possible to implement
> it on top of Kawa's JVM object system too.
>
> These individual datatype SRFIs with prefixed procedures will still be a
> necessary first step, though. The interface methods can be based on
> them. Once an object system SRFI is approved, a common container
> interface SRFI could be imported without having to import them individually.
>
> On 10/8/20 1:23 PM, Per Bothner wrote:
> > 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.