This page is part of the web mail archives of SRFI discuss from before July 7th, 2015. The new archives for SRFI discuss contain all messages, not just those from before July 7th, 2015.
> From: email@example.com (Michael Sperber [Mr. Preprocessor]) > >>>>> "Alex" == Alex Shinn <firstname.lastname@example.org> 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