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]) > >>>>> "Alfa" == Alfa Male Petrofsky <firstname.lastname@example.org> writes: > >> From: email@example.com (Michael Sperber [Mr. Preprocessor]) > I'm confused. You said that > > > 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. > > ... so your proposal just won't cut it. (I see numbers attached to > the names. What are they?) They are the shortname serial numbers. Did you ever read the message that started this thread? Here's the proposal again: Each SRFI will have a title and a shortname. Just as with the title, the shortname is chosen by the author, and may change during the revision process. The title may be any latin-1 string (as now), and the shortname may be any r5rs identifier (a case-insensitive string in a subset of ascii as described in r5rs section 7.1.1). When a SRFI is finalized, it is assigned a shortname serial number: the lowest positive integer that has not been assigned to any previous SRFI with the same shortname. Any srfi may be unambiguously and concisely referred to in announcements, manuals, papers, other SRFIs, etc., as "SRFI n", where n is the SRFI number, or as "SRFI shortname-m", where m is the shortname serial number. Systems that support SRFIs 0 or 7 should allow srfi-n or srfi-shortname-m as feature identifiers for SRFIs. > But the fundamental question remains: I *still* fail to see what > problems you folks are expecting to solve substantially better than > the status quo does it. I have to wonder if perhaps this is because you haven't been thoroughly reading the messages to which you respond. I recommend, again, that you try re-reading the archive. > From: David Rush <firstname.lastname@example.org> > I think that again we have two sepearate discussions taking place > here. There is a desire for a non-numerical scheme for assigning > feature identifiers associated with SRFIs 0 & 7, and there is a need > for a document reference standard. And I still think these are the same issue. We have a unique name (the SRFI number) that can be used in programs and in documents to concisely refer to a particular SRFI. What I would like is an alternate, easier-to-read-and-remember name, that can be used in exactly all those contexts that the numbers are used now. > However, I also would prefer that the SRFI process not become a > mmethod of canonicalizing extensions to Scheme. I thought it was > supposed to be a feeder process for RnRS. > Personally, I am not dissatisfied with using (essentially) numerical > feature identifiers. In some ways I prefer them because it leaves room > for me to associate my own feature identifiers with user libraries. I'm not suggesting that a library system would need to support the name string-lib as the name for a library that implemented SRFI 13. I'm only suggesting that if a system allows you to refer in some way to SRFI 13 with the identifier srfi-13, that it should also allow you to refer to it as srfi-string-lib-1. Note the "srfi-" prefix. I don't see how this is infringing on names likely to be used by rnrs or by your own code. Really, all I'm suggesting is that the names for distinguishing SRFIs from one another be drawn from a slightly richer character set than just #\0, #\1, #\2, #\3, #\4, #\5, #\6, #\7, #\8, and #\9. -al