Am Sa., 22. Apr. 2023 um 06:28 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> [Moving the thread to srfi-discuss since it's no longer about SRFI 227.]
>
> > you have to call them (srfi <number> <srfi-name> <library-hame>); you
> > can't omit the supposedly optional <srfi-name>.
>
> A decision should be made about that. Does (srfi <number>
> <sublibrary-name>) make sense or not, given that (srfi <number>
> <srfi-name>) exists?

This would be logically incorrect as it would not cover the edge case
where the name of the sublibrary coincides with the name of the
library.  This edge case has some chance of appearing in practice.

> > Of course if we had keywords in library names ....
>
> We already kind of do. In R6RS we use (import (srfi :123)). It's wise to
> prepare for a scenario where R6RS and R7RS are merged, and some of the
> implementations additionally support keywords with : prefix syntax.

I hope the suggestion to use keywords in library names was on a
lighter note.  A SRFI name is conceptionally just an identifier
(however, one that is allowed to be an ordered compound of symbols and
not just a single symbol).

As I remarked several times, for some syntactic extensions (like local
imports), we need at least the name part of a library name to be a
symbol (so that it can carry lexical information).  The best we can do
for R7RS-small names is to somehow map a number like 227 internally to
:227.  The positive side effect is that R6RS and R7RS names for SRFI
library names become then interchangeable (simplifying porting).  The
upshot is that we don't want to give different semantic meanings to a
number or the ":"-prefixed symbol arising from the number in library
names and library name parts.