naming modules

[Klaus Schilling <Klaus.Schilling@home.ivm.de>]

Jim Blandy 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?
 > 
 > 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

Will contributed modules be distinguished somehow from the posix stuff that 
comes now with the main distribution? 

 > 	(shell ...)   Exec'ing Unix commands, parsing arguments, etc.
 > 	(net ...)     networking
 >         (gui ...)     GUI toolkit interfaces, and related things
 > 	(math ...)    Mathematical functions

The gsl wrappers might fit there, along with chrlib and jacal ?
 > 
 > (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.

Should games get a subhierarchy in app, so that modules specific to my 'naos'
would be (app games naos ...) ? 

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

Curses doesn't fit anywhere in those categories ... Is Maciej's (terminal ...)
or (tty ...) still in the game? Or is chaos suited for that?
 > 
 > 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.
 > 

Do important tools like hobbit and g-wrap count as app or get an extra 
hierarchy?

   Klaus Schilling