[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SRFI naming

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.



As has been discussed on comp.lang.scheme, the naming scheme for SRFIs
has become unwieldy: keeping thirty different numbers straight is
beyond the mental capacity of those of us who inhaled questionable
substances in college, and using the full titles is both too verbose
and unamenable to embedding in an identifier.

Here's a proposal:

   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.

That's it.  I think this greatly relieves the obscurity problem
without introducing any authority problem.  I imagine we could go to
well over a hundred SRFIs with very few shortname serial numbers
higher than two.

To assign shortnames to all the already finalized SRFIs, we would want
to poll the authors, but here's a stab at an initial list, derived
from usenet posts of Stephan Houben and felix:

   SRFI number
   |   Shortname                
   |   |                           Shortname number
   0   cond-expand                 1
   1   list-lib                    1
   2   and-let*                    1
   4   homogeneous-vectors         1
   5   signature-let               1
   6   string-ports                1
   7   feature-cond                1
   8   receive                     1
   9   define-record-type          1
   10  sharp-comma-syntax          1
   11  let-values                  1
   13  string-lib                  1
   14  char-set-lib                1
   16  case-lambda                 1
   17  generalized-set!            1
   18  multithreading              1
   19  time-date                   1
   21  real-time-multithreading    1
   22  unix-scripts                1
   23  error                       1
   25  make-array                  1
   26  cut                         1
   27  random-sources              1
   28  format                      1
   29  localization                1

-al