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

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

Jim Blandy writes:
 > 
 > Here's a thought; I'd appreciate folks' comments.
 > 
 > 
 > The primary purpose of hierarchical naming is to avoid naming
 > conflicts.  

Aggreed.

 > 
 > 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
 > 
Giving some more examples to show If I understood the principle:

(scwm ...) --- features designed as part of Stachowiak's scwm
(gtk ...) --- stuff from M.Vollmer's gtk bindings for guile
(lang ...) --- stuff that provides the parser- ,lexer- etc. tools for
	       language translation.
(hobbit ...) --- necessary tools for using the hobbit compiler with guile
(stk ...) --- bernard urban's stk interface bindings.
(gdbm ...) --- Archibald's interface to the GNU database manager

 > 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)
 > 
That sounds just fine.

 > 
 > 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'.
 >
Sounds ridiculous.
 
 > 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?
 > 

For modules that are especially written for one project, or standard, this 
looks like the best solution.

 Now it happens that modules arise from projects that are widely useful, like
in the case of M.Stachowiak's optargs, which come with scwm. It's clearly
useful for many purposes that are by no means related to GUI managing. I use
to put stuff like that in a path called util, thus (util optargs).
 


 Klaus Schilling