Am Mo., 21. Feb. 2022 um 21:02 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Mon, Feb 21, 2022 at 2:38 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>> With respect to individual identifier names, I can follow this
>> argument once a standard is adopted; R7RS-large, however, is still in
>> a state of flux.
>
>
> It is most misleading to say so.  SRFIs, whether adopted as part of Large or not, can be changed only by errata or by PFNs.  Errata of course can go on as long as anyone is still interested:  an erratum for C11 could be issued today, but we do not say that C11 is in a state of flux because of that.  A PFN can be incorporated into Large by a vote of WG2 as long as the Committee is still active, but there are severe limits (which Arthur could explain better than I) on how much change a PFN can actually introduce.  (Daphne is, I think, urging us to adopt a third process, or perhaps to adopt a non-SRFI process for new proposals: I don't know which yet.)  It is of course true that there are many proposals which have not been voted into Large, and they are partially in flux: the specific proposals are not yet chosen and neither are their names.

As far as I see it before the Steering Committee is asked to endorse
the final product, any change can still, in principle, be made.
Nothing prevents us to vote, say, some hypothetical SRFI 301 into
R7RS-large, replacing SRFI 1 in some incompatible way.

>> With respect to library names, I don't see much of a problem with
>> aliasing if there is an agreement on interoperability with the R6RS
>> standard as well.
>
>
> I do not know what "agreement on interoperability" means in this context.

If there's an agreement that a valid R6RS program should be, as far as
practical, also a valid R7RS-large program so that maintaining a
codebase that works both in R7RS-large and in R6RS implementations is
possible. Think of C and C++.