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

Re: SRFI naming



>>>>> "Mike" == Michael Sperber [Mr Preprocessor] <sperber@informatik.uni-tuebingen.de> writes:

>>>>> "al" == Alphanumeric Petrofsky <alphanumeric@petrofsky.org> writes:
    al> As has been discussed on comp.lang.scheme, the naming scheme for
    al> SRFIs has become unwieldy: keeping thirty different numbers
    al> straight is beyond the mental capacity of those of us who
    al> inhaled questionable substances in college, and using the full
    al> titles is both too verbose and unamenable to embedding in an
    al> identifier.

    Mike> Could anyone remind me exactly what problem needs solving
    Mike> here?  I'm not sure I understand.

Al* just explained as simply as could be: numbers are hard to remember.
Yet these numbers are referred to and listed everywhere regarding
SRFI's, from feature summaries, to Scheme documentation to actual
programs (either via feature-cond or a module system).  Not only is it
difficult for experienced Schemers to remember, it has the form of a
secret code that others have to learn before they join the Scheme cabal.

Many examples were given of these numbers being awkward in programming,
requiring lookups, being cryptic if feature comparisons of Schemes, and
also of scaring off newbies and outsiders to Scheme.  An actual excerpt
from the start of one of my modules:

  (use srfi-1)
  (use srfi-2)
  (use srfi-11)
  (use srfi-13)
  (use srfi-14)

does this really not seem like a problem to people?  And please don't
argue

  (use srfi-1)   ;; list-lib
  (use srfi-2)   ;; and-let*
  (use srfi-11)  ;; don't even remember...
  (use srfi-13)  ;; string-lib
  (use srfi-14)  ;; char-set-lib

is better because I can remember the name when writing the module the
first time around, but would still have to refer to a reference card to
get the number.  I'd like to think that after some experience with a
language I wouldn't need a reference card to write programs.  And
anyway, it's just plain aesthetically displeasing and makes Scheme look
like a backwards language.  And this isn't about modules... I'd like to
see summaries of which SRFI's a Scheme supports and not have to
cross-reference all the numbers.

-- 
Alex