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