Am Mo., 27. Apr. 2020 um 17:38 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

[...]

>> It would be good if the Scheme community came to a set of rules for managing the “namespace” of library names, beyond reserving (scheme …) and (srfi …) and (<scheme-system> …).  Specifically, I think a library name starting with a URL should be automatically reserved to the person or organisation that controls that URL.

I agree it is a good idea to have some management of namespaces. I am
not so convinced about the use of URLs for that purpose. (Apart from
aesthetics, will `https://www.nieper-wisskirchen.de' and
`http://www.nieper-wisskirchen.de' be different URLs for that
purpose?)

If the library names become long (like with URIs), it would be nice
each Scheme system allows to use or install a mapper (a simple
association) from long names to short names so that I can access
libraries as `(nieper foo)' instead of
`(|https://www.nieper-wisskirchen.de| foo)'. If we go this route, we
can drop URLs altogether and replace them with UUIDs, which everyone
can generate (version 4 UUIDs). In fact, they are shorter than most
URLs and no less pretty in library names.

> I wonder if it's better to recommend that all URLs be enclosed in vertical bars, which is safe and simple as vertical bars are not valid in URLs unless %-escaped, or to specify that only URLs containing characters from "#[]'(),;" be enclosed, which minimizes the use of vertical bars.

Many R7RS systems don't define the mapping from library names to file
names for library names that include characters like the slash or the
dot.  There may be other limitations.

>> Also, a library name starting with an underscore should be reserved for the Scheme implementation, and have a meaning that depends on the Scheme implementation.
>
>
> By reserved, you mean that it is not to be imported from user code?  If so, I am fine with it.  If not, my objection is that if you get some code that imports (chibi ...) and you try to run it on some other implementation, you will probably get an unknown module error.  But if it imports (_foo ...) and your implementation is using that name you don't know what will happen.

Do we really need this? Instead of `(_foo)', where `_foo' is supposed
to be internal to Chibi-Scheme, it is already enough to put the code
in `(chibi foo)' to make it private. The further conventions about the
library namings inside the implementation namespace should be up to
the implementation. psyntax, for example, uses `$' to mark internal
libraries.

> In any case, I think putting such modules under the implementation petname is probably good enough.

Indeed.

Marc