> On Apr 27, 2020, at 11:54 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> 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?)

That’s to be debated, but frankly I think the protocol part “http[s]://” should not be part of the library name in general.

>
> 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.

Adding vertical bars should only be needed if… it is needed.  There’s no point in forcing it if the name is a correct symbol.

>
>> 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.

It is something that became useful as a way to easily specify builtin names on the command line for Gambit, i.e. to do

   gsi _hamt/test

rather than

   gsi gambit/hamt/test

It doesn’t seem like much difference at first sight, but with this idea of permitting library names on the command line you can start using them as a kind of flag to enable certain modes of execution, like quiet testing:

   gsi _test/quiet _hamt/test

rather than

   gsi gambit/test/quiet gambit/hamt/test

The shorter “_” prefix makes a difference and almost looks like the “-” in front of normal options.

Marc