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 would symbols and numbers be encoded differently? What practical
benefits are conferred by keeping them different, and what practical
harm comes from treating them as equivalent?
> 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.
Are the practical implications for Scheme programmers or implementers?
It's the whole library name that is of interest. Any part ought not be
interesting on its own.
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.
Following the Chez lineage: Ikarus and Vicare are unlikely to have
active users. Loko and Unsyntax are still young.
The existing, widely used support for numerical library name parts in
R7RS is a big deal. Successive editions of RnRS should not vacillate in
order to make abstruse technical points. There has to be a serious
blocker. I am willing to hear if there is, but the obstacles explained
so far seem to me either trivial or outside the remit of RnRS.
Aesthetics matter when they are not mostly subjective.
There is more variety in taste than I expected. Nevertheless, the fact
is that there are two widespread existing conventions. We should make
them interoperate.
