Am Mo., 22. Juli 2024 um 20:13 Uhr schrieb Lassi Kortela <la...@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.
