The issue isn't with SRFIs as such, but with R7RS-small; there is no way for an implementation to communicate to its callers what features it does or does not support at or before compile time.  In SRFI 115, for example, there are various features that can be tested by cond-expand, but this is not very helpful, because there is no portable way to add a cond-expand feature.

As a result, the resence or absence of the feature would have to be hard-coded into the implementation, which would not realize if its implementation were replaced by another either more or less capable.



John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Rather than making ill-conceived suggestions for improvement based on
uninformed guesses about established conventions in a field of study with
which familiarity is limited, it is sometimes better to stick to merely
observing the usage and listening to the explanations offered, inserting
only questions as needed to fill in gaps in understanding. --Peter Constable


On Fri, Jan 24, 2020 at 10:57 AM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
On Fri, Jan 24, 2020 at 7:30 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
 
Arthur and John know best about this topic, but I got the impression
that SRFIs are not intended to have optional parts. If optional features
are desired, the custom is to put them in a separate SRFI which has a
dependency on the other SRFI containing the core procedures. Cross-SRFI
dependencies are fine when they serve a purpose, and there are many
existing examples of them.

The SRFI process document doesn't say anything about optional features one way or the other.  There are some SRFIs that specify features that are required only conditionally, e.g. if the core implementation has the full numeric tower.  I'd generally prefer that SRFIs only have that kind of optional feature, but that's just a preference.