>>>>> "Alex" == Alex Shinn <xxxxxx@synthcode.com> writes:

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

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

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.

Here's an excerpt from the start of one of my modules:

  (require (lib "list.ss" "srfi" "1"))
  (require (lib "string.ss" "srfi" "13"))

Neither the former nor the latter is mandated by the SRFI process as a
whole.

Now of course, I can see that people want to turn some SRFI documents
into libraries in the context of one or the other
library/package/module system.  And of course, I can see that they'd
like to use symbolic names there.

The main problem with assigning these symbolic names to the SRFI
documents, rather than the 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.  I haven't seen any proposal that addresses this problem
in any adequate matter, and I'm personally reluctant to endorse one
that doesn't.

Now, symbolic names have their place in a fixed library collection
proposal, akin to the Standard ML basis or the Haskell library report.
There's no problem with having such a proposal: write one up and
submit it as a SRFI.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla