Daphne,
I've been considering your advise during last few months. And here's my
thinking and reply:
1. I will remove NAME-XXX format so that there'll remain :XXX and
srfi-XXX two formats.
2. I will add XXX format(R7RS restricted and equivalent format).
3. Giving all libraries names is too complicated and I chose to follow
SRFI-95's form.
在 10/7/25 13:45, Daphne Preston-Kendal 写道:
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.
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.
To repeat what I have said before multiple times: every SRFI which exports
identifiers should have a library name. If the SRFI also modifies lexical
syntax, there also needs to be a way to activate the SRFI at the lexical level.
The key word is ‘also’. These are two independent levels as far as the Scheme
language is concerned; activating lexical syntax can never activate a library’s
exports, nor vice versa. If this SRFI does not want to deal with the question
of how lexical syntax is activated, that’s fine (though I don’t really
understand the hesitation to address this problem) – but for libraries (like
SRFIs 4, 88, 89, 207) which either introduce or depend on a lexical syntax
extension, one*also* needs a way to import the identifiers they use.
Simply repeating the mistake of SRFI 97 by continuing to exclude SRFIs with
library exports is not a good idea. It is an even worse idea when it
delegitimizes the decisions of authors who have already independently seen
through that nonsense reasoning and decided to fix it.
Please either fix this SRFI or withdraw it. Finalizing it would be a disaster.
