> On Apr 27, 2020, at 12:14 PM, Peter Bex <xxxxxx@more-magic.net> wrote:
>
> On Mon, Apr 27, 2020 at 11:38:10AM -0400, John Cowan wrote:
>> An excellent idea for a no-code SRFI that would be easy to write for people
>> who haven't written one before.  It should specify both the
>> petname convention and the URL convention.  Attention should be drawn to
>> mailto: URLs, which allow people who don't control any conventional URL to
>> have their own library namespace.
>
> Assuming/hoping there will at some point be a registry where one can
> download r7rs libraries (maybe there already is? snowfort?), I think it
> can be as simple as suggesting people use their library name as it occurs
> in the registry as a prefix.

A registry would be useful but it should not be the only way to name libraries.  A registry forces authors to register their libraries for every new library they want others to use.  But that can become a rather tedious process, especially if you are into rapid development and sharing a new idea “right now”.  I want to put the library up on my github account and share the link… a 60 second process at most.

>
> This is lightweight, easy to understand and remember, and not as ugly or
> fraught with issues like the URI proposal.
>
> For programs, one could use the main binary's name as a prefix.  If the
> binary is going to be installed into PATH under the scheme system's bin
> directory, that has to be unique already, anyway.  And if it's installed
> somewhere else, it shouldn't cause any problem as long as the search path
> for binaries matches the search path for libraries (e.g.., first the
> current working directory, then system paths).
>
>> 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.
>
> That would be a problem because then you'd need an additional mapping of
> URL to filesystem location for the module.  A colon is not allowed in
> Windows file names, more than one dot might be a problem in some OSes as
> well, and slashes can't occur in file names either.  There's many more
> specifal characters:
>
> https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations
>
> So an e-mail address might not work either.

My main point is for library names that include a URI (at the head) to be under the control of the person or organisation that controls that URI (or mail address).  This avoids the need for a registration step and is lightweight (no administrativia involved for the author).

Marc