Re: naming modules

[Maciej Stachowiak <mstachow@mit.edu>]

jimb@red-bean.com writes:
> 
> (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?
> 

Sounds great to me.

> 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.
> 

I agree with all this (duh, since it largely agrees with what I wrote
:)

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

That sounds good to me. Do you think these should still be registered
or should we just not worry at all about collisions in (chaos ...)?

> 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.

The reason I suggested `lib' is because `slib' and `scsh' are, in my
opinion, fundamentally different sorts of name components than `posix'
or `net' or `www'. I mean, if tsort did not come as part of slib, we'd
probably expect it to be under (sort tsort), not (slib tsort), since
the feature it provides falls in the general category of sorting, not
slib. Slib just happens to be what it comes with.

This is why I suggested the (lib ...) and (app ...) categories in the
first place - to segrate things that ought to be named by package name
(for lack of better options) from things that are named by logicaal
category.

I wouldn't be too opposed to mirroring bits of slib or scsh in the
functional hierarchy if people think that makes sense, but under names
that do not include `scsh' or `slib' or whatever. 

Perhaps this topic merits further discussion.

Another concern is, what do we do about things that would fall in more
than one category with about equal claims? For instance, (net smtp)
makes sense for a low-level SMTP module, but should low-level ftp and
http be in (net ...) or (www ...)? Arguments could be made for
both. Of course, www could be placed under net as a whole, but I am
not sure that makes sense, for instance (www cgi) would have at best a
tangential relationship to networking. This point is not raised so
people will argue it out now, but more to suggest that we need to
figure out a process or policy for dealing with similar issues when
they come up.

 - Maciej Stachowiak