Am Mo., 22. Juli 2024 um 10:13 Uhr schrieb Taylan Kammer <
taylan.kammer@gmail.com>:

> Thank you for the comments. I agree especially with the part about RnRS
> needing to define a broad-ranging standard that allows writing useful
> libraries in a portable way. The lack of e.g. networking primitives is
> extremely limiting and this always greatly bothered me about RnRS.
>
> I have questions about your point #4 though.
>
> On 21.07.2024 11:54, Marc Nieper-Wißkirchen wrote:
>
> > Allowing numbers in library names makes certain syntactic extensions (as
> some found in Chez Scheme) impossible.
>
> Do you have a pointer to some resource that explains this in more detail?
> It's the first time I'm hearing about it and would like to learn more.
>
> > In the syntax-case model of R6RS (which is also the basis of Guile's
> expander), only identifiers like ":1" carry lexical information (a set of
> marks and substitutions in the R6RS model), numbers and other Scheme datums
> do not.
>
> I've always thought of library names as data, not identifiers...
>
> In R7RS, both 'define-library' and 'import' kind of exist "outside" the
> rest of the language, in a sense, and treat library names as literals.
>
> - 'define-library' must be the outermost form read from a
> file/stream/whatever, and neither the library name being defined nor any of
> the library names in 'import' sub-forms are subject to variable lookup or
> any such mechanisms that otherwise affect Scheme program evaluation; the
> library names are all treated literally, like data.
>
> - 'import' (when not used a 'define-library' subform) must appear one or
> more times at the start of a sequence of forms read from a
> file/stream/whatever that describes a program, and the library name
> operands are again not subject to variable lookup or such, but rather
> treated literally as if data.
>
> - The only other entity in R7RS that deals with library names, if I
> remember correctly, is the 'environment' procedure, which expects library
> names in the form of data (lists).
>
> In what kind of situation might a library name be made up of identifiers
> (syntax objects) that might need to carry lexical information?
>

I was talking about certain syntactic extensions. In Chez Scheme, which is
an extension of R6RS (and strictly compatible with it modulo bugs),
"import" is also a keyword, and libraries can be imported into a local
environment. In this case, the library name is part of the syntax. To
correctly attach marks (in the R6RS syntax model) to the imported
identifiers, the expander needs marks associated with the library name (and
takes the marks of the last name part, which, therefore, must be an
identifier).

Local imports make perfect sense; they are just not standardised in current
RnRS versions, i.e., in R6RS and R7RS.  Likewise, future standards may
allow library forms within Scheme program text.  The R7RS choice of
allowing numbers is, thus, suboptimal because it may rule out certain
future extensions.

I guess there is another reason why R6RS disallows numbers as library
names: this can lead to confusion with library versions, which are also
numeric (and which R7RS does not have).  People coming from other
programming languages or environments are used to numbers as version
indicates (e.g., we have libguile-2.2.so and libguile-3.0.so), while "(srfi
1)" does not mean the first version of some SRFI library. (We really need a
better naming scheme for SRFI libraries that does not depend on assigned
numbers, but it is not clear to me how to implement one.)

Cheers,

Marc