> From: xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr.  Preprocessor])
> >>>>> "Alfa" == Alfa Male Petrofsky <xxxxxx@petrofsky.org> writes:
> >> From: xxxxxx@informatik.uni-tuebingen.de (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 <xxxxxx@bellsouth.net>

> 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