Am Mo., 22. Juli 2024 um 20:13 Uhr schrieb Lassi Kortela <
lassi@lassi.io>:
> As I wrote, this is a syntactic extension of Chez Scheme - but a very
> useful one - and outside of the R6RS. The Unsyntax expander I wrote
> also implements it.
If patching these two implementations to use the first library name part
instead of the last is the only technical obstacle to numbers in library
names, it seems the cost is trivial.
There are other costs involved, e.g., when mappings from library names to the pathnames have to be specified. While it is straightforward to encode a number of characters like "/" or ":", it is not so straightforward to encode numbers differently from symbols that look like numbers.
> Why not take the first library name part instead of the last?
>
> The last name part is the most specific one.
What does that mean, and what are the ramifications?
Intuitively and semantically, it makes more sense to derive the needed lexical information from the most specific library name part than from a generic top-level name part.
> the R7RS authors were
> likely unaware of the incompatibility of their proposal to allow numeric
> name parts with existing implementations and language extensions.
Implementation, singular.
Singular only insofar as Chez Scheme is the only affected implementation that I know. Ikarus was another existing implementation that may support the Chez extensions as well as may any other implementation whose expander is close enough to Chez's.
> I don't buy that numeric library parts are particularly useful; they are
> just one option. The SRFI 97 convention works as well as the SRFI-0
> convention of "srfi-N" names, which is basically also used by Guile.
Aesthetics matter.
Aesthetics matter when they are not mostly subjective.