Am Sa., 22. Apr. 2023 um 08:25 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > 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).
>
> Are you referring to the following passage in SRFI 97?
>
> "There is opportunity for grouping related SRFIs together. For example,
> SRFI 28, Basic Format Strings, and SRFI 48, Intermediate Format Strings,
> could be grouped into a common format library with simple and
> intermediate components. This has been avoided, preferring instead to
> follow a one SRFI, one (top-level) library convention. Although within a
> single SRFI, several sub-libraries can be defined, thus achieving
> grouping. This simplifies the naming convention and prevents the need
> for a naming authority which decides what shall and shall not be grouped
> together. Instead, grouping must be achieved by the SRFI process, as it
> should."
>
> SRFI 97 gives the following examples:
>
> (srfi :41 streams primitive)
> (srfi :41 streams derived)
>
> But it is silent on how to use sublibrary names without main library names.

(srfi :41) is just an abbreviation for the compound library (srfi :41
streams).  That's all, and that's fine.

> Should we never use a sublibrary name without a main library name? That
> violates the spec of some existing SRFIs that were written with R7RS in
> mind, e.g. SRFI 160 says (srfi 160 base).

SRFIs designed for R7RS haven't used the SRFI 97 convention.  The SRFI
97 convention also uses the pluralized names of R6RS, which R7RS
doesn't.

> > 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.
>
> The right thing is (symbol->string '|123|) => "123"
>
> R6RS doesn't have |...| syntax but I hope we can get past that in
> implementations.
>
> Making the :123 hack equivalent to 123 is something that should be
> solved on an ad hoc basis in the library loader. Hacks shouldn't go into
> RnRS.

It's no hack; it would be a convention.  You can't solve it externally
in the library loader alone as I tried to explain above because you
need to fabricate lexical context for some syntactic extensions.