On Wed, Jan 22, 2020 at 6:52 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> > Having more procedures doesn't add complexity, but having more
> > *exported* procedures does.  Each one is another attack surface for
> > penetration testing, another bit of documentation, another  item to
> > master in order to master the API.  I have in general gone much further
> > in this direction, following Olin Shivers's SRFI 1, than many people
> > think I should have.
>
> While that is true, it's also an inherent property of successful
> general-purpose languages that they do a lot, and do it conveniently.
> The long-term trend is toward all software converging into one system
> (we just can't agree on whose system that should be).
>
> I'm in favor of your and Olin's comprehensive approach for libraries and
> it pushed my own thinking more in that direction. I don't always see the
> point of a particular procedure in a SRFI, but if it's logically
> specified (and they generally are) I give it the benefit of the doubt.
>
> I also think there's a point to having a mix of minimalist SRFIs and
> maximalist SRFIs (maximalism is a word in some circles).

With library support in r6rs and r7rs we could even have the best of
both worlds: have core procedures in (srfi N) and convenient/utility
stuff in (srfi N extra) or something. Scheme implementors could choose
to support just (srfi N) if they prefer minimalism.
--
Duy