Naming modules (was: Re: getop-gnu-style.scm)

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

> Gordon Matzigkeit writes:
>  > Hi!
>  > BTW, my convention has been to use the (gnu ...) packages as Scheme
>  > equivalents of C header files on a GNU system.  So (gnu argp) contains
>  > the stuff that would be in <argp.h>, (gnu errno) does <errno.h>, etc.
> 
> So should termios.h stuff go into (gnu termios) ? 

To be honest, Gord, I'm not sure how I feel about this.  /usr/include
is such an amazing mishmash of everything under the sun that I don't
think that's a very useful organizing principle.

Here's a thought; I'd appreciate folks' comments.


The primary purpose of hierarchical naming is to avoid naming
conflicts.  

Having intuitive names is also good, but I don't think think it should
be the defining principle here.  First of all, it's too vague; what's
intuitive to one person is obscure to another.  And finally, it's
clearly not necessary; a Guile module's name is analogous to a C
library's header file's name; and people today already happily refer
to documentation (or source) to find the right header to #include.
So I think intuitiveness should take a secondary role to good
conflict avoidance.

One way to avoid naming conflicts is to delegate sections of the
namespace to projects.  So, I would suggest:

  (guile ...)  ---  modules that are part of the Guile interpreter.
  (gush ...)   ---  modules written for Gush's purposes
  (posix ...)  ---  modules providing features specified by POSIX.
		    Klaus's termios would go here.
  (scsh ...)   ---  features designed as part of the SCSH package

Both GUSH and SCSH want to provide access to the system.  If we were
to follow Gord's original suggestion, I can imagine both of them
introducing things that would go under (gnu ...).  However, if we
divide the namespace by project, Gord is unlikely to introduce
GUSH packages whose names conflict with other GUSH packages.

Thus:

  (guile repl)
  (gush argp)
  (scsh getopt)  --- I think Olin actually has something like this
  (posix termios)


Of course, this doesn't prevent two groups from both introducing a
package called `www'.  We could imitate Java and have people use their
domain names to distinguish things, but that has always struck me as
very clumsy.  And people don't do it anyway; Per Bothner is
introducing classes called `guava.foo'.

You'd also like your naming system to give some confidence that module
names won't change often.  I guess the project-name-prefix approach is
okay in this regard.

What do folks think?