> From: xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr.  Preprocessor])
> >>>>> "Alex" == Alex Shinn <xxxxxx@synthcode.com> writes:

> Alex> Many examples were given of these numbers being awkward in
> Alex> programming, requiring lookups, being cryptic if feature
> Alex> comparisons of Schemes, and also of scaring off newbies and
> Alex> outsiders to Scheme.

> Alex> does this really not seem like a problem to people?

> Sure.  But, as has been pointed out on comp.lang.scheme, SRFIs aren't
> modules.  They aren't libraries.  They are documents.

Examples were also given of these numbers being awkward for referring
to the documents in non-module, non-library contexts: feature
comparisons, implementation announcements, manuals, and usenet
articles often must refer to SRFIs.  A module system is just one
context in which people refer to SRFIs.  The fundamental problem is
the inability to unambiguously refer to a particular SRFI document
without having to remember which one of thirty numbers was assigned to
the document.

> The main problem with assigning these symbolic names to the SRFI
> documents, rather than the libraries,

(Again, my concern really is about referring to the documents, not
libraries.)

> is that there's likely to be duplicate candidates for names, even if
> there aren't many now.  Enforcing a qualified naming scheme to avoid
> this makes the symbolic names much less useful and creates much the
> same problems as with the srfi-n names.

My proposal does indeed have an arbitrary-serial-number component to
it, and thus does theoretically suffer exactly the same problem.  The
thing is, this whole problem is one of degree, and if the problem is
sufficiently diminished, it is no longer a problem.

I have no problem with occassionally distinguishing between two things
by arbitrarily numbering them 1 and 2, and in my code I will sometimes
name two variables simply x and y rather than minuend and subtrahend.
Perhaps your ability to deal with this extends as high as thirty, and
thus the current SRFI naming system is not only adequate for you, but
optimal.  For many of us, however, thirty is way beyond our limit.

Currently, I don't think there are any two SRFIs that would want to
use the same name, so adopting my proposal would reduce the largest
number that must be remembered from thirty to one.  I think duplicate
names would be quite rare, and the number of SRFIs could easily go
into the hundreds without any large subnumbers arising.

As Alex Shinn pointed out, the perl community has had success without
the subnumbers by simply giving out names on a first-come-first-serve
basis, with the editors occasionally rejecting requests for
overly-generic names.  That sounds workable to me, but my proposal is
a little easier for the editors.  Presumably, most SRFI authors will
choose a unique name on their own, but if two of them really want just
plain "foo", then they can both have it.

-al