Per is committed to a classical OO implementation of Scheme, so of
course monomorphism seems just an annoyance to him. But I concluded a
decade ago that there will never be a consensus on the One True OO
System (which is why I have ruled out standardizing any of them in
R7RS-large (modulo an appeal)), and still less on the One True Class
Hier/Heterarchy. As long as the names are kept as consistent as
possible, I don't think having lots of them is a burden on the mind,
though it may be a burden on the fingers. In addition, fast-generics
from Chicken and particular typeclasses should help.
You made the right call IMHO.
I wouldn't suggest splitting this collection. It just has to be
anarchic enough so that there is no bias towards certain idioms.
Well, let us say, to minimize bias. One of the reasons for having so
many SRFIs with the same procedures over and over is to help with the
problem of "Oh, data structure X is perfect for what I want to do, but
it has so few (or no) procedures (that I would have to write myself)
that I'll just use lists instead, which have lots of procedures."
It's true that a large language should have lots of convenience
procedures (Mathematica is probably the most extreme example of this).
But unless I misunderstood him, Marc was making a different, orthogonal
point: that there should be a separation between "core" procedures that
are required for an efficient and portable implementation of the
functionality, and "convenience" procedures that can be implemented
fully in portable code by relying on the not-efficiently-portable
"core". The convenience procedures are much more subject to taste than
the core ones, so they could benefit from a different release process,
with possibly more than one group working on a user-friendly "skin" on
the core stuff.
For example, there could be a monomorphic skin with different procedures
for each data structurem and another OO-style polymorphic skin such as
Kawa would like. Also a functional skin and an imperative skin, etc.
If SRFIs dealt mainly with the core stuff, the design work involved
ought to be less controversial (e.g. the things required to implement an
efficient data structure can be figured out from CS textbooks and
studying known performance characteristics of different virtual
machines) and we'd arrive at a minimal portable API on top of which
other projects could build.
