Am Di., 23. Juli 2024 um 17:06 Uhr schrieb Lassi Kortela <la...@lassi.io>:
> > 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? > In R7RS, (srfi 1) and (srfi |1|) are different library names. > > > 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. > Parts of Scheme forms can be interesting even if they do not make sense as stand-alone identifiers. > > 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. > Your reply is out of context. We were talking about the creation of R7RS, which happened more than ten years ago. > 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. > I agree with the last point; a future RnRS can special-case "(srfi N)", demanding that the library described by it must be the same as the library "(srfi :N)". The latter would be the default and numbers in library names otherwise deprecated. Numbers would be reserved for versioning.
