Ok, this discussion doesn't feel extremely urgent, but it's not that hard, and it has to be done some time or later, so let's begin.
- It strictly replaces Gambit's current namespace functionality. You
can load object files that are compiled with it, but that's about how far you get in terms of interoperability. IME Gambit's namespaces simply aren't nice to work with.
(I'll like to discuss this when I'm looking at it. As I've discussed with James Long some time (*), I wonder if renaming couldn't use Gambit's namespaces too and conversely code using Gambit's namespace feature couldn't be made accessible cleanly from automatically- renaming code.)
(*) http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Module_System/Log
When I think about it, it is not that hard to interface to "legacy" code, using the namespace system. The module system actually uses it internally. Only partially, and I'm hoping to remove it relatively soon, because as I said, it's not nice to work with, but the naming convention namespace#identifier is used and I don't see why that would change.
The module system (ehhh... we ought to find a good name for it) is built on top of the notion of packages, which is a rather powerful mechanism. It should be possible to write code for a package that uses namespace. (Package is the word I use for a collection of modules) The problems I see are these:
Other people might be thinking differently than me here, but I really think that namespaces shouldn't be picked by the user. The way to distinguish modules ought to be a more flexible one. It is really the same problem as prefixing in C, except that in this case there is a really clean solution IMO:
Because namespaces aren't explicitly shown to the user (except when debugging), the module system can choose a namespace for the module when compiling. (There must be a machine-global dictionary of taken namespace names or equivalent to ensure consistency.) This means I can make a CGI module, call it cgi.scm and release it. Someone else might make a different CGI module and call it cgi.scm. With this system, the modules can coexist, the first one installed will get the namespace cgi#, the second one might get cgi-2#.
To me, this is an important feature, both because it hides needless complexity from the user (choosing a namespace, which is redundant work to choosing the file's physical location) and it doesn't require ad-hoc prefixes. The current "solution" seems to be that I ought to call the file something like pe-cgi.scm. To me, this solution sucks, because to be able to make complex software, you need to use hundreds of modules and organise them in a tree structure and I don't see how that fits neatly together.
There are more reasons to why the module system should generate namespaces, mostly related to what a future ruby gems-equivalent tool would benefit from.
Anyways. The problem I see is simply this: All "normal" modules will have a machine-generated namespace, to avoid name clashes. This impossible to do with the old system, so namespace clashes might happen.
The second problem I see is the one with dependency tracking. The system is based on the fact that it is able to track and automatically load dependencies. I don't see how that is done with namespaces and the #.scm convention.
Well, these are the initial problems I can see. It's definitely possible to cook together a hack that is able to load most code, often without problems. A completely clean solution is more difficult.
/Per