Email list hosting service & mailing list manager

Re: Overuse of strings Lauri Alanko (24 Jan 2006 17:59 UTC)
Re: Overuse of strings Per Bothner (24 Jan 2006 19:51 UTC)
Re: Overuse of strings Alan Bawden (25 Jan 2006 00:44 UTC)
Re: Overuse of strings Alex Shinn (25 Jan 2006 01:39 UTC)
Re: Overuse of strings Per Bothner (25 Jan 2006 02:04 UTC)
Re: Overuse of strings Alan Bawden (25 Jan 2006 02:50 UTC)
Re: Overuse of strings Lauri Alanko (25 Jan 2006 18:19 UTC)
Re: Overuse of strings Neil Van Dyke (25 Jan 2006 19:07 UTC)
Re: Overuse of strings bear (25 Jan 2006 22:40 UTC)
Re: Overuse of strings Lauri Alanko (26 Jan 2006 07:35 UTC)
Re: Overuse of strings Alex Shinn (26 Jan 2006 01:37 UTC)
Re: Overuse of strings Neil Van Dyke (26 Jan 2006 02:03 UTC)
Re: Overuse of strings Anton van Straaten (26 Jan 2006 10:09 UTC)
Re: Overuse of strings Lauri Alanko (26 Jan 2006 10:25 UTC)
Re: Overuse of strings Alex Shinn (26 Jan 2006 02:17 UTC)
Re: Overuse of strings Ray Blaak (26 Jan 2006 06:56 UTC)

Re: Overuse of strings Lauri Alanko 26 Jan 2006 10:22 UTC

On Thu, Jan 26, 2006 at 10:37:02AM +0900, Alex Shinn wrote:
> The recommended approach would probably be to use a URN (rfc2141):

Also note that there is a relatively new URI scheme, "tag" (rfc4151),
which just provides a simple domain- and email-based naming scheme in a
URI format. If all that's required of library identifiers is that there
are no accidental collisions, then tags should be as good an answer as
any.

Then again, the problem with that is that we also care about brevity,
and it would be a bother if the standard language for most modules had
to be identified with, say, "tag:schemers.org,2006:/r6rs". Of course
one could define a default base uri of, say, "tag:schemers.org,2006:/",
but then one couldn't use relative references to easily refer to one's
own nearby modules...

SRFI-84 seems to propose yet another non-standard naming system with
the benefit of conciseness for most common references in Scheme world
(RnRS and SRFI-n), but at the cost of some adhocness and lexical
problems (symbols embedding full http URIs). And of course personally I
don't like the idea of stuffing structured data into a single symbol,
no matter how it is organized.

Maybe the easiest thing to do would be just to chicken out and say "a
library path is either a URI _or_ one of these magic special things
like r6rs or srfi which are not really URIs but for which we provide
these short forms since you're going to use them all the time".

Lauri