[ cc'ing xxxxxx@srfi.schemers.org which is a better place for this
  discussion ]

>>>>> "Ben" == Ben Goetter <xxxxxx@mazama.net.xyz> writes:

    Ben> Quoth Ulrich Kaufmann:
    >> Does anyone think that a debate comprising, at the last count, 62
    >> messages

    Ben> Debate?  I don't see any debate.  I see one Java(tm) programmer
    Ben> who replies to every message in this thread.

Well, there's also at least a Perl programmer (hopefully that doesn't
discredit me too much on this list :)

    Ben> Elsewhere, I see an overall consensus: We Need Modules.

Most definitely.  That is probably the single biggest problem facing
Scheme right now... until we get a module system, the average Scheme
script will never work on more than one Scheme, no matter how similar
the Schemes in question.  It limits our ability to share code - anything
from one Scheme always requires munging to work with another.  That's
just sad... I know of no other language with a formal standard for which
that is the case.

However, naming is a different issue.  As has already been pointed out,
SRFI-0 and SRFI-7 both refer to "feature identifiers" and SRFI-0
specifically mentions there will probably be the need for aliases for
these identifiers.  Ideally these identifiers would also be used in a
module system, and likely in general discussions/comparisons/changelogs
of Schemes to give a more meaningful description than some number.

The only real argument that has turned up against names is that numbers
are less ambiguous.  This is true.  And assembly is less ambiguous than
higher-level languages, and machine code even less so.  Sound
frequencies are less ambiguous than musical notation.  Latitude and
longitude are less ambiguous than the name of a city.  But it's easier
to work with names.  Consider the recent discussion of the "begin" form,
where the appropriateness of the name was called into question because
the form serves two purposes.  Nobody proposed resolving the ambiguity
by renaming it "primitive-1".  We agree sometimes we'll get names wrong,
and are willing to revisit and change names at times, but nobody
actually programs by number.

So I don't think at this point anyone is actually arguing against
descriptive names, the question is really what naming process we use.
Specifically, how do we address naming conflicts when two SRFI's
introduce the same idea?  For many things this is not an
issue... "list-lib" defines basic list operations that haven't changed
in decades and aren't likely to be superceded by another SRFI.  Rather,
new SRFI's might define additional operations on lists, for example
"sort-lib."  But other concepts like "objects" or (alas) "modules"
aren't so simple and may well have many different SRFI's.

One proposal is to suffix conflicting SRFI's with a "serial" number
(optionally always requiring a serial number).  This is very easy for
people to remember but can be misleading... objects-2 could be either an
improvement over objects (maybe by the same author) or it could be an
alternate proposal that doesn't even use the same style.  If such an
approach were taken people would simply have to remember that these
numbers indicate historical order, not necessarily version or relation.

Another proposal is to require a sponsor prefix.  In Java this is
formalized with a domain name convention, in Scheme this could just be
the sponsor or project, e.g. "meroon.objects," "smalltalk.objects," or
"clos.objects".  Examples were given of all the various GUI systems,
where you might have "gtk.ui," "kde.ui," or "ncurses.ui".  The problem
here is it can be cumbersome when you really don't think the sponsor
prefix is warranted... for the aforementioned list-list, "olin.list-lib"
seems a little wordy.

Yet another option is to do what CPAN does (I don't know of any other
public code repository as large or successful), which is to let the
authors decide what they think is best.  The CPAN maintainers do have
veto ability... they can refuse if you want to create a module called
"Regexp," or "Objects" but in general people *want* their names to be
descriptive, and people know that those names aren't very helpful to
users.  It is mostly self-regulating.  Of course, SRFI's are not a "code
repository" but the naming issue is the same.

In summary: we need names that are easy to remember, but we're not yet
sure what those names should be.  There is still room for debate.

--
Alex