(Sorry Christian, I forgot to Cc this mail to the list, so you'll get this mail twice)
Christian Jaeger wrote:
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.
You haven't said what isn't nice.
* When do I use ##namespace and when can I use just namespace? It's a little bit odd.
* The fact that (namespace ("foo")) and (namespace ("foo" bar)) does two completely different things is definitely not nice. (namespace ("foo")) ought to be something like (namespace "foo") instead. Automatic tools need to be careful not to insert an empty list of identifiers that belong to a namespace, since that is something completely different.
* I find (namespace ("foo")) quite difficult to tame. It's easy to mess up lots of things, including the repl when working with it.
* Maybe I should have been clearer in what I meant with the "namespace system": In my eyes the ##namespace directive is very closely tied to the concept of having separate #.scm and .scm files, and the way it is used in practise is broken in my opinion.
Using namespace prefixes for the automatic naming of identifiers deems me a good idea for these reasons:
- code always needs to specify a dependency somehow; so you will
always have the problem of unique global naming in some way or another.
Yes. My point was that using prefixes is a solution that is much inferior to other possible solutions.
- the idea to group together modules into packages, so that you can
locally name the other modules and hence can use simple naming, looks sensible or at least interesting (although global naming for remote dependencies is not solved by this, and making two ways of dependency selection maybe adds some additional complexity).
It does add additional complexity, but I don't think it adds too much. Especially since I am using the concepts of relative and absolute paths, which ought to be familiar to most Unix people.
I think if you spend some time checking out how this module system does it, it might be more clear how it approaches these problems.
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.
What do you mean with "tree"? Filesystem tree? Would you take the filesystem tree 1:1 for the naming in dependencies? Then you still got the problem of conflicts, it's just going from pe-cgi to pe/cgi. (But you might have that "local naming" advantage as above--do you mean this? Are packages living in a "subfolder" for you? Or are they more akin to lexical scoping, where the outside world can't see the inside names?)
Every package has its own "filesystem". If you, from a module called foo, do (use bar), it searches for the module bar in the same directory as foo. If you do (use /foofoo/bar), it searches for the module /foofoo/bar in the package foo resides in.
To reach the package from outside, an entirely different nomenclature is used: (use ([package resolver name] [arguments ...]))
If the package resides in a CPAN-like repository, cpan is the package resolver for that repository, and the package name is foobar, you might write (use (cpan foobar /foofoo/bar)) to use the /foofoo/bar module in that package.
So to answer your question: A directory containing a file called Packagefile is considered a package. It has its own tree of modules, mapped 1:1 to the filesystem. For inter-package dependencies, package resolvers are used. Package resolvers can be configured either globally (standard library, CPAN) or per-package.
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.
You should tell more.
See above. This actually completely removes the problem of name clashes because it is configurable per package.
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.
(I don't think code using ##namespace manually will ever want to load a module of a module system; only the inverse. I.e. code using ##namespace will be at the leaves of the dependency tree. Usually anyway, maybe it's useful for hacking to be able to call module system loader functions from that lower level.)
What I meant was "legacy" module inter-dependencies. Of course, if there are none, this is a no-issue.
/Per