> [+srfi-discuss]

Thanks for broadening the audience. Good call.

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

+1

> Attention should be drawn to
> mailto: URLs, which allow people who don't control any conventional URL
> to have their own library namespace.

I'd advocate focusing on web URLs and only supporting other types if
that falls out naturally from the overall design. There are now tens of
thousands of hosting sites where anyone can get their own web URLs for
free, both conventional GeoCities-style webhosts as well as social sites
like GitHub that give everyone a github.com/username.

Of course, if a library name part can be a URN (Uniform Resource Name,
https://en.wikipedia.org/wiki/Uniform_Resource_Name) that's one way to
solve the problem. We can do the same thing we did for Unisig
(https://github.com/unisig/unisig) where the default URI scheme is
whatever protocol is the most popular way to transfer web pages at any
given time (previously http, now https, in the future http/2 or
something else).

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

I'd recommend simply not using any fancy URLs. A simple
"foo.com/bar/baz" with lowercase [a-z0-9], dash, slash, and dot ought to
be enough for almost everything.

I guess we can permit arbitrary URIs (or URNs), and people can them use
vertical bars for portability.

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

Gambit has library names beginning with an underscore already. Most of
those can be imported from user code, but only if the user knows the
code doesn't need to run in other Scheme implementations.

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

Good point. It might make sense to have the "_" alias in the interaction
environment only, meaning that source files need to import using the
name of the implementation.