Okay. Another attempt:
I have very dated experience with Java, but in my opinion Java packages seem to have two parts in practise: Take the class org.apache.cactus.internal.configuration.DefaultFilterConfiguration as an example. In my mind I split it into
org.apache.cactus || internal.configuration.DefaultFilterConfiguration
With bh, org.apache.cactus is the package, /internal/configuration/ DefaultFilterConfiguration is the module path and DefaultFilterConfiguration is the module name. /internal/configuration is there simply as a means of organizing the internals of cactus, org.apache.cactus is there as the global unique qualifier.
As I see it, there /must/ be a way of doing the right hand part of this; projects must be able to split themselves up into a filesystem like structure. I have never ever seen any other way that works. Moving /internal/configuration/DefaultFilterConfiguration to /internal/ DefaultFilterConfiguration should require a rename of all uses of the module, because this is a file system like thing.
org.apache.cactus is there as a means of guaranteeing the uniqueness of the java package. I don't like this solution, because it yields very long names which in practise makes it impossible to code Java without a fancy editor like Eclipse.
I don't think the CPAN way of having a central repository would work; This is Scheme. I don't think we'll be able to unite around one central system. Even if one system becomes standard in practise, people will want to have the power of being able in theory to make a better one.
The motivation behind this design is that it allows for a clean, non- name-clashing way of providing unique names to everyone's code without resorting to very long names or forcing one central thing on everyone. Comparing to the Java approach, this is like allowing local shorthand names (ie let cactus be an alias for org.apache.cactus) at the same time you explicitly state the path to the package. ("let cactus be an alias for the package at /home/per/prog/cactus")
Also, this can be combined with a (or more than one) central repository, which will remove the need of configuring where each dependency is located on the local computer.
One more advantage of this is that it is very easy to do simple hacks that won't go anywhere. If I create a file called foo.scm, it is by definition a module that can be loaded. I might then feel like adding one more file, bar.scm and use foo from it; no problem. Later on, I might realize that this is some great software that ought to be distributed. No problem; I just create a Packagefile in that directory and it is a package, ready for distribution. More people might like it and i might even decide to publish it to the central code repository.
It is easy to create code that other people can use, which IMO is one of the greatest problems with Gambit right now. Nowhere in this process will I have to rewrite anything to make it fit a bigger audience. No worries about namespaces or name clashes.
Another advantage of this kind of approach (it might not be unique to it, though) is that it's clear by the look of the use form what kind of import it is: (use (... ...)) refers to something external, (use /...) to something not very closely related to this module, (use ...) to something in the same directory as this file.
This is in contrast to ruby, where a 'require "json"' might refer to json anywhere in the system, it's impossible to tell.
Christian Jaeger wrote:
I see moving a module happen if it fits better in another package, if another author takes over maintenance of it but not the rest of the original package.
I still cannot see a real-world example of this. One package is not = one maintainer. One package is one functional entity, like HTTP utilities. When I want to load some cookie tools, i use /cookie-tools from the http-util package.
/Per