Per: I checked out the module system you sent to the list (black hole?) and I'm unclear how it is meant to be used. There is no documentation and the 2 examples are really too simple to grasp the possibilities. I could read the code... but I feel it would be best if you gave a quick tour of how your system is supposed to be used.
Cool. I will write some kind of documentation for black hole asap, hopefully quite soon.
Over the last week I have been working a lot with cleaning up the code and adding a couple of features, primarily being able to import only some things from a module, renaming, and proper separation between compilation phases. The last feature required a change in the fundamental data structures of the hygiene system, and I'm still fighting the last bugs that came out of that. I'd encourage anyone who is interested in reading the code of black hole to wait until that is done, hopefully today or tommorow.
If anyone is interested, I can make the current version public, but I don't think it'll help because some things are broken, and I think it will be difficult to understand how to use it then.
Do I understand correctly that it does not require a "module" special form to wrap the module or be put as a header?
Yes, black hole does not use a "module" wrapper special form. The reasons for this are that it allows complete code compatibility with plain R5RS code, which is good thing in my opinion, plus it gives a more lightweight "feel" to it, which I also think is nice.
An objective I have is to design the Gambit module system so that it can support several other module systems, such as black hole, Jazz, Chicken, Bigloo, PLT, etc. With this feature, a user could access in his code, libraries that come from different communities with their specific module conventions. That would be a great step forward for Gambit!
With the features i have implemented this week, only a syntax-case implementation is required to be roughly feature compatible with most module systems I know of. (I might very well have missed some important points though) This should be rather simple to implement, check out syntax-rules.scm, which is the syntax-rules implementation. It's 264 lines long, took a day to write and I have found only a couple of minor bugs in it since I wrote it.
Right now I think that the best way to implement compatibility with many different module systems is to make it explicit in the import statement which kind of code you're importing. This takes away any confusion about which kind of code it is. Also it's compatible module system where each module is more than one file, and it is possible to extend to fancier things like a pseudo module type that can act as ruby-gems, or something similar.
I'm thinking that the idea of http://catdancer.github.com/lib.html might fit in here, I love the simplicity and sheer decentralized power of it.
Of course, this can be combined with a "default" module kind, which is able to parse formats that are easy to distinguish.
/Per