I would like to reiterate that my email yesterday was arguing *against* this or any new convention for naming SRFI libraries, so further criticism seems perhaps redundant :-)

To summarize, my wish is that this SRFI should

(1) specify that an identifier library name component of the form :⟨digit⟩⁺ should be treated by implementations’ library managers  as equivalent to an exact integer name component, for R6RS compatibility/historical reasons only

(2) recommend the use of SRFI 97-style library names in the ‘R7RS style’ i.e. when exact integers are used in library names, so libraries might now canonically be called e.g. (srfi 1 lists), (srfi 9 records), etc.

(3) add #!srfi-xyz reader directives for accessing lexical syntax

To the criticism of the third point:

> #!r6rs-4 cannot work because the #!-syntax is not delimited. With
> #!srfi-4, there could be no #!srfi-44.

It appears this is the case of #!r6rs in the R6RS report (by oversight?), but the R7-small report says of the #!fold-case and #!no-fold-case directives that ‘it is ungrammatical to follow a ⟨directive⟩ with anything but a ⟨delimiter⟩ or the end of file.’ (p. 62)

There would be no problem with a SRFI on this requiring the #!srfi-xyz reader flags to be delimited, and no inconsistency at least with the R7RS.

Since, as the original SRFI 97 pointed out, there is a problem with using a library which depends on lexical syntax extensions when those extensions are not available, I think the problems of accessing SRFIs’ defined exports and accessing their defined lexical syntax are closely enough intertwined with one another that it makes sense for one SRFI to handle them both.

Daphne