Am Di., 25. Okt. 2022 um 20:37 Uhr schrieb Marc Feeley - feeley at
iro.umontreal.ca (via srfi-discuss list)
<xxxxxx@srfi.schemers.org>:

[...]

> > Yes, but what you're proposing changes the first element of library names from a simple identifiers into something structured that has a special interpretation.  That's why I prefer the idea of using an extension of the standard library-name syntax.  Relying on the fact that many URIs are legal identifiers feels like a hack.
>
> On the contrary! It shows the foresight the RnRS authors had in allowing so many characters in symbols. Moreover, note that the delimited symbol syntax |...| allows any character to be put in a symbol (just like the "..." syntax for strings), so a symbol is just a more “human friendly” kind of string and it works quite well for URIs (I have never encountered a web site where a delimited symbol is needed, probably because it is in the interest of web site creators to use a name that is human friendly).

I agree that symbols are sufficient and that we don't need strings or
some extension to the library name syntax.  The only issue I would
have with a symbol like github.com/mnieper is that it encodes some
hierarchical information, usually encoded as a structured Scheme
datum.  But that's a minor complaint.

[...]

> > Would someone else like to join us in this bike shed?
>
> I’m sorry to hear you feel discussion on the library naming issue is bike sheding... I think it is a critical issue that is hindering the sharing of Scheme libraries. Having a standard layout for publishing libraries is fundamental. Without it the total work required is O(N x M) rather than O(N x 1), where N is the number of Scheme implementations and M is the number of library layouts in use (and it seems M is close to N).

To summarize (and to check that I understood everything correctly):

Marc's proposal has two facets, which are somewhat independent but can
work together:

1. A convention for top-level library name parts ("github.com/feeley")
that solves the namespace issue without needing a centralized agency.
As a side effect, this convention can be exploited by automatic
installers if they wish so, but this is not part of the actual
standard for the convention.

2. A standard for laying out a Scheme package (a coherent unit of
Scheme libraries possibly bundled with further resource files) so that
Scheme-system-specific installers only need to support this
distribution format to install published packages.  As a side effect,
this standard layout can be directly supported by a Scheme system,
reducing an installer for such a Scheme system to a mere copier.

Marc