Am Di., 7. Okt. 2025 um 07:45 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> As long as the issues I have raised repeatedly throughout the draft phase are unaddressed, I feel that finalizing this SRFI would damage the Scheme community and make writing portable code harder. It will create needless extra diversity in SRFI references rather than trying to fix the problem, making it harder either to write portable code or to write an implementation which supports as much portable code as it could, or both. The problem of a diversity of options in referring to SRFI libraries cannot be fixed by creating more options! I have referred to xkcd 927 before, but that is still literally what this SRFI proposes to do. After finalization, an implementation of both R6RS and R7RS will need to support yet more variety in SRFI name references.
>
> The only way to make this better and not worse is to unify the two existing conventions:
> • an R6RS library name component of the form :<digit 10>+ must be equivalent to an R7RS exact integer library name component, and implementations should look for such libraries in files whose names do not contain a leading colon (which is the entire ‘problem’ this SRFI really seems to set out to address, an invented ‘problem’ since neither R6RS nor R7RS say anything about a standard mapping of library names to file names)
> • R7RS SRFI library names should be able to include the SRFI 97-style name identifiers; the current syntactic ambiguity about R7RS library names of the form (srfi nnn <identifier>) should be resolved by saying that <identifier> must not be a sublibrary name in future but a reference to the ‘whole’ SRFI library itself, with (srfi nnn <identifier> <identifier>+) being used for sublibrary divisions.

For the Scheme user, this would mean that one can then write uniformly
"(srfi :XXX)" without having to distinguish between R6RS and R7RS. It
would need cooperation by implementations, though, because of the
suggested mapping from library names to pathnames. (On the other hand,
an implementation may share my opinion that SRFI libraries should be
provided by the implementation - possibly in a tailored way - natively
and not be installable like any other library, in which case the
problem is also moot.)

> Moreover, it has still not been addressed that the ‘omits’ SRFIs from naming which actually already have names in their library metadata on srfi.schemers.org. Examples, I reiterate, are SRFIs 4 and 207. This SRFI needlessly throws the legitimacy of such authorial library name assignments into question. Arthur, I think as SRFI editor you ought to step in here and at the very least prevent this from happening. It would be damaging to the SRFI process to allow any doubt to be sown about whether such names are valid references.

Every SRFI author is free in what they suggest, aren't they? If in
some SRFI XXX, it is suggested that SRFI YYY should be amended in some
particular way (or imported in some particular way), that should not
need consent by SRFI YYY's author. I don't think it is good if the
SRFI editor makes decisions regarding content (vs form).

What I do think is important is that everyone remembers that a priori
a SRFI's contents only reflect the opinion of its author and that it
doesn't (necessarily) reflect the consensus of the Scheme community.

That said, I agree with you that it is advisable to suggest to an
author not to finalise a SRFI if there are still important open issues
raised by the community.