> Many libraries are written to get things done or to support a particular
> programming style. Such libraries have their place in such a collection
> even when they shouldn't be standardized in any way (e.g. by turning
> them into a SRFI). One example is the λ syntax of Schemepunk. It is the
> same as the regular lambda except for treating (λ x e) as (lambda (x) e)
> instead of (lambda x e). This makes the behavior of λ rather irregular
> (so shouldn't go into a standard), but this doesn't mean that it
> shouldn't be published to used by those people who like this kind of
> idiosyncrasy. In fact, this may simplify some SRFI discussions when
> SRFIs can concentrate on those things where there is consensus and where
> no idiosyncrasies of a particular programming style are involved because
> everything else could be moved to the proposed collection of libraries.

Great point. Indeed, a practical library collection should be convenient
(within reason).

This also give snew insight into SRFIs. Maybe they would best serve the
role of building blocks or internals. Convenience and presentation is
somewhat fickle and subject to taste. But the internals have to do with
efficiency and reliability.

For example, a heap SRFI could provide the essentials that are needed to
make a fast and space-efficient heap in a portable way, and others could
provide the convenience procedures on top. This would also make it
easier to write SRFIs, since good "engine" primitives are easier to
understand than the totality of all use cases and what is convenient for
each of them.

Classic SRFIs like 1 (list library) and 13 (string library) are an
argument in the opposite direction, and John in particular has followed
this precedent in his SRFIs, but all these SRFIs have been written in a
time where Scheme doesn't have a de facto standard light process so
there wasn't the option to make any kind of standard any other way.