> I think this is a great idea.
Me too, but with an important addition: I think this kind of names
should be used only when a module in package A accesses a module in
package B.
There should be a way for a module in package A to refer to a
sibling/child module in package A without referring to the full name
of A. There should be a way to import bindings from "the module named
C at the same level as me" or "the module named D among the modules
only visible in my name space".
When programmer Q writes her module B (a large system) and partitions
her problem, she discovers that she needs module D.
It is likely that she encounters some problems similar to programmer A
(c. f. the obligatory dynamic vector template in C++ ;-), and it is
not at all unlikely that programmer A also used a module named D, and
we get a collision.
This shows the need for a hierarchical name space: Programmer Q want
to be able to "hide" the module D in the name space of B.
For modules which are specific to the B system it is even more natural
to let D be a sub-module. In this case, D may want to refer to B.
But consider now what happens if we decide to rename module B. If all
sub-modules of B refer to B by an absolute "path", we need to change
many other modules as well.
Consider also what happens if programmer G writes the mega-module M
which uses both A and B. He wants to be able to just copy modules A
and B into his hierarchy and only care about the absolute paths to A's
and B's interfaces. In most cases, it would be a better solution for
G to let his distribution install A and B alongside with M, but this
is not the point. The whole point with the module system is that we
should abstract away all of its internals, and only care for its
interface. This should extend to the naming as well. We shouldn't
need to worry about at what place in the name hierarchy we decide to
install modules A, B, or M.
To sum up, we need a hierarchical name space with relative references.
Note how the file systems has converged to the, now common, use of a
hierarchical name space with both abolute and relative references.
(Note also that file systems have links. I'm thinking of the multiple
"structures" (approximately "interfaces") of the Scheme48 module
system... :)
> I think the module name needn't identify the source (core vs. contrib
> vs. goldman-sachs). It seems to me that each source corresponds to an
> element of the load path:
Yes, removing this part of the module name gives additional
flexibility when other packages refer to the module in question. With
the scheme proposed above, this will not affect references internal to
a package.
[...]
> "goldman-sachs" corresponds to whatever packages are developed
> locally, which I guess corresponds to /usr/local/share/guile/site.
> (Is this case really useful to distinguish? Shouldn't we encourage
> each site just install its local packages alongside the rest? That
> would encourage people to think about module names carefully from the
> start... If this makes sense to people, I'll remove "site" from the
> default load path.)
I think it is very good to keep "site" in the load path. This is
because it is very important to be able to easily differentiate
between "pure" standard packages and packages mutated by the system
managers. At our institute, e. g., you don't get a pure Emacs when
you type "emacs". Instead, you get an Emacs with lot's of changes and
fixes, unknown to you, in miscellaneous packages. In this situation,
it is very good to be able to place "lisp" in front of "site-lisp" in
your `load-path (or "core" in front of "site"!).
> There's a fourth category that nobody's mentioned yet: "personal".
> Stuff that's only installed for one user's benefit. I'd personally
> put this in ~/guile, and say "./configure --prefix=$HOME" before
> building a package; should load-path include $HOME/guile by default?
Yes! Very good idea.
Best regards,
/mdj