naming modules

[Jim Blandy <jimb@red-bean.com>]

(Hoping to resurrect a promising topic...)

If there is a way to manage the namespace to keep it useful, I would
love to have a module's name reflect its purpose, rather than its
origin.  The basic problem here is that it requires centralization.
Left to their own devices, even reasonable, in-touch developers will
choose categories in slightly different ways, the namespace will turn
into chaos, and the original intent, to have names that make sense,
will be lost.  We would need a group of people who would agree to
manage the namespace, and make recommendations to module authors.

I'm not a heavy Perl programmer, so I don't know much about CPAN, but
I looked around their site, and found this
(in http://www.perl.com/CPAN-local/modules/04pause.html):

    Register your namespace!

    Please, talk to modules@perl.org before you decide upon the
    namespace you're going to use for your module. Usually it's not
    considered the perl way to have bureaucratic conventions, but when
    it comes to namespace pollution, there is the need of
    coordination. Just like the InterNIC has to care for unique names
    for internet hosts, somebody has to (sort of) guarantee
    uniqueness, consistency, and sanity of module names. The
    modulelist is the place where all currently registered module
    names can be found and the email address modules@perl.org is an
    alias for a hand full of experienced volunteers who maintain the
    module list and give advice for the appropriate namespace for your
    modules.

In other words, this job requires a central authority, so they have
one. 

Maciej wrote:

    I think the right way to avoid naming conflicts if we allow
    generic categories like `posix' is to have a central registry of
    Guile modules, much like CPAN. I am willing to maintain or
    co-maintain such a registry and repository if someone else can
    provide the space.

I think this is a great idea.  I can find space somewhere, and I'm
willing to help run the archive.  Guile isn't up to Perl's scale yet,
so I think a normal web site and FTP archive should serve our needs
fine for now, no?

As far as naming conventions go, here's my idea for the next iteration:

Names by logical category
    The name reflects the features provided or the job done by the
    module.  Examples:
        (posix ...)   POSIX stuff
	(shell ...)   Exec'ing Unix commands, parsing arguments, etc.
	(net ...)     networking
        (gui ...)     GUI toolkit interfaces, and related things
	(math ...)    Mathematical functions

(guile ...)
    Modules that come with the Guile core, and don't fall nicely into
    one of the categories above, or give access to some part of the
    Guile interpreter (and whose logical category is therefore
    "guile"!).  Low-level interfaces that are tamed by some other
    module would go here too:

        (guile debug)	        interface between a debugger written
                                in Scheme, and Guile's interpreter
	(guile internal load)	all the weird load variants, that 
				get redefined by the module system

(app APPNAME ...)
    Modules that come with an application and only make sense in the
    context of that application.  For example, SCWM might provide its
    functions here.

(chaos ...)
    Safety valve, like Usenet's `alt'.  Guile and the Guile modules
    group will never complain about anything anyone puts here.

Maciej's proposal included (lib ...), "for externally developed
libraries/comprehensive packages which are not guile-specific and have
their own organization."  I've dropped that, because it seems to me
that those could just go in the "names by logical category".  Names
can be nested as deeply as we want; what's wrong with:

	(shell scsh field-reader-package)    reading lines with fields
	(slib tsort)                         SLIB's topological sort module

I think we're almost agreed.