As mentioned in a previous mail, I think the ideal naming convention for SRFI libraries, considering both ergonomics and the rules of R6RS, would have been of the form (srfi cond-expand-0), (srfi lists-1), etc.

People seem to like this idea.

Unfortunately, I also think that ship probably sailed with SRFI 97’s finalization; the situation where R7RS small allowed libraries with exact integer components in their names already led to one other competing convention. Adding another convention now (whether the Guile-like one this SRFI currently proposes, or the one I proposed) would risk only increasing the confusion.

My original intention was to propose to the R7-large WG (for the bibliothecarial fascicle or a non-normative appendix thereto, i.e. not for a year or so yet) that a library name component which is an identifier starting with a colon, followed only by ASCII digits, should be understood by implementations as equivalent in all respects to a component which is an exact integer consisting of those decimal digits. This would be understood as an R6RS compatibility provision.

On reflection, I still think that is a better solution, especially if we can also agree to start using the library names in the R7RS-style names.

What this SRFI could do:

Most obviously, this SRFI could recommend exactly that equivalence between :<number> and <number> as library name components.

The original SRFI 97 should have been much less conservative about the set of libraries it gave names to. It should have given names to all libraries that export identifiers, even if they also add lexical syntax to the language, and even if the proposals of those SRFIs were ‘subsumed’ by R6RS. Some of those cases have been fixed (SRFI 4 was excluded by SRFI 97, but is now called ‘numeric-vectors’ according to the SRFI metadata).

Some have not; also, as has been noted, many SRFIs since SRFI 97 have not been given names by their authors.

SRFI 261 is an opportunity to fix these cases by adding library names to all previous libraries that don’t have them.

On the problem of lexical syntax, I think SRFI 261 should also take the opportunity to formalize the convention #!srfi-xyz for a reader flag which enables the lexical syntax defined by the SRFI with number xyz. That would mean that #!srfi-88 would enable reading literal keyword objects with DSSSL-like syntax, for example. The precedent for this is, for example, the flag #!srfi-237 from Marc’s record types SRFI.

The flags would enable exactly the lexical syntax of that SRFI without disabling any other lexical syntax (except in the hypothetical cases of lexical syntaxes which are incompatible with one another, or where a SRFI explicitly states otherwise). So ‘#!r6rs #!srfi-4’, for example, would (properly implemented) enable R6RS syntax, with only the extension of SRFI 4. Any other SRFI lexical syntax would be a violation. A subsequent ‘#!r6rs’ would turn SRFI 4 back off again.

Just my tuppence-’orth,

Daphne