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

[Maciej Stachowiak <mstachow@mit.edu>]

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

I think the problem with things like (gnu termios) and (gnu errno) is
that it's not intuitive or logical.

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

I'd like to to suggest a somewhat different naming system, and a
different way to avoid naming conflicts.

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 the right naming scheme is actually a hybrid system rather
than strictly by package. Actually, upon further reflection, that
really is what you are proposing except I'd rather state it
explicitly. I think there are four categories of modules to consider:

1) Modules that come with the Guile core.  

2) Modules that are meant to be useful for all guile applications in
general, and extend Guile with new features. Klaus's termios module
would fit in this category.

3) Modules that come from a externally developed libraries of useful
Scheme code which already have their own organization, such as scsh or
slib (I think slib should eventually be available through Guile's
native module facility).

4) Modules that are specific to a given application and are not useful
outside that application. I propose paritioning the namespace like
this:

* (guile ...) for modules from category 1 which do not fit well anywhere
in the category 2 hierarchy. The repl would be a good example of this.

* Naming by logical category of features provided for modules from
category 2. For example (posix ...) for posix stuff, (net ...) for
networking, (gui ...) or (toolkit ...) for gui toolkits, maybe (util
...) for general-purpose language facilities like hiegenic macros, or
my optional argument stuff, etc. Some modules from guile-core should
most likely go into one of these categories rather than (guile ...).

* (lib <library name> ...) for externally developed
libraries/comprehensive packages which are not guile-specific and have
their own organization. Since these packages are likely to organize
things their own way which may not be compatible with any plan we come
up with, it's probably best to segregate them into their own
individual corners. So there'd be (lib slib ...), (lib scsh ...)

* (app <application name> ...) for modules that come with an
application and only make sense in the context of that
application. For example, scwm or siag or aisleriot might want to
provide modules of library code that's quite useful to scripts or
extensions for these programs, but not otherwise. (scwm at least
already does so and already follows this convention).

I guess the main difference between this proposal and Jim's is that I
advocate special prefixes for library-specific or app-specific code
(mainly to nicely segregate it), and that I propose that projects that
ship generally useful code in addition to the app itself should put it
in the generic functionally defined namespace.


However, I am more attached to the idea of having a globally
recognized naming convention in general than particularly this
specific convention, especially if we have a central registry. The
naming of Guile packages is quite arbitrary and ad-hoc as it is.

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

To address this specific example, I hope Gord makes much of this code
generally useful even outside of GUSH. Obviously there will be some
GUSH-specific items such as his implementation of fast-loading applet
scripts; but I get the impression he plans to implement many things
like syntax translation and access to system facilities that many
people have wanted to be general Guile features for quite some time.


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

The only one of these I'd disagree with is (gush argp). I don't think
all sorts of packages should be reimplementing argp functionality, and
that therefore Gord's argp package should be placed somewhere as
generic as (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'.
> 

Domain names suck, especially for free software projects which cannot
easily be assigned a specific domain name in many cases. I think
SunSoft was trying to solve an entirely different class of namespace
conflict issues that Guile will likely run into; Sun was mostly
concerned with classes provided by proprietary developers working for
a company, since they likely expected independent work to be
"hobbyist" material not to be taken seriously. OTOH Guile is probably
much more concerned with modules that are developed by free software
hackers and intended to be shared. It's remotely possible that people
will create proprietary guile modules, and maybe even that they will
distribute them. But I am doubtful this will happen to the extent that
different people want the same name for their proprietary modules.

Of course, my proposal to apply functional category naming as broadly
as possible causes a slight problem if two different people both want
to create a termios interface. But I am not so sure this is
necessarily a problem. I'd rather see people work together on packages
for Guile that want to provide the same functionality than to
endlessly spawn their own versions. It's true that in the Scheme world
people are picky about interfaces and have wide variation in tastes;
but I think perl has benefitted imensely from the effort-pooling
incentives created by a central repository with modules named by
functional category.

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

True, but I think a central repository will ensure this even better.

 - Maciej Stachowiak