General comments

[Lassi Kortela]

> Arguably that's a feature - in Scheme you'll always be sure of the
> performance characteristics of the type you're working with, and you'll
> always know what type you're working with.  Also, by not having generics
> for collection types you avoid quite a performance overhead related to
> dispatch. But I understand many people disagree that this is desirable.

While RnRS collection procedures are monomorphic, users can easily add 
generic ones. IMHO the latter should be standardized in the future.

(RnRS number procedures have always been generic, so I see generic 
collection procedures as a natural evolution of Scheme.)

> Besides just being "etched in stone", the SRFI process has been hijacked
> by a small group of people and is producing SRFIs at breakneck speed with
> perhaps not enough community input.  Usually by the time I learn about a
> SRFI about a subject I find interesting, it's already finalized ;)
> That makes SRFIs rather "take it or leave it".  And often they're not
> especially ergonomic either.

Agreed by many people, myself included.

To those who have a few spare cycles, please help me try to alleviate 
the problem. There is now an experimental alternative at 
https://groups.scheme.org/review/ to ease the constraints that cause 
problems with SRFI. Namely, the time pressure to finish proposals and 
the focus on "requests for implementation" are gone.

All that's needed to get going is for people to submit a couple of 
proposals. It would even be possible to source eggs from the proposals' 
git repos.

I announced this on srfi-discuss which generated a lot of discussion but 
no holy war ensued. The thread is here: 
https://srfi-email.schemers.org/srfi-discuss/msg/21408058/