Hi.

I have finally decided it's time to release the embryo of a module system that I have written. Some things worth noting:

 License:

I don't know what license to distribute it under, so right now I have decided to not choose any formal license at all and just informally state that you're free to read and poke around with the code. The reason for this is a thread on the gambit mailing list a while ago that was about adding a BSD (or MIT) style license, but someone said that if that should be done there is little reason to keep the LGPL/Apache. To me it seems like it's best if this is resolved before people actually start working on improving this piece of code. I'm not particularly biased towards any license, but I do think a simpler license scheme is better than a complex one all else being equal.

 expr.scm:

The tarball contains a file called expr.scm, which is almost entirely written by Christian Jaeger. Other than that, all code is written by me.

 What it is:

The initial goal for this was to provide a simple and intuitive way of organizing code in larger projects. It shares many similarities with the Java package system, in particular that the module's name is directly mapped to the file system. To be able to do this neatly with macros, it also contains a system for hygienic macros which is based on syntactic closures. On top of this there is a R5RS syntax-rules implementation. Even though most serious issues have been nailed down, there are still a couple quite basic problems left to be dealt with.

 Some inherent limitation of this kind of design:

* 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.
* define-macro gets tossed away. There's a lot to say about this topic, so I'll leave it until later. This version of the code does have define-macro, but in practise, it doesn't work.
* The namespace#identifier notation is more or less reserved for internal and debugging use. There are a number of reasons for this, I won't take them here.

 Usage:

* Untar the package.
* (optional) Alter conf.scm to taste. It shouldn't be required to test the basic functionality. The main things that are set here are compilation options and package resolvers. This configuration will get compiled into the module system object file, which kinda sucks, but I haven't wanted to fix it yet.
* (optional) Compile the thing: Issue a "gsc build"
* To actually use the system: do (load "build") from the REPL (with the appropriate path of course). I have set up a simple shellscript that does this for me.


 To test things, you could for instance do this:

;; See the hygiene in action
(expand-macro '(let ((a #t)) a))

;; syntax-rules support
(define-syntax test (syntax-rules () ((test) #t)))
(test)

;; Load a module (make sure to be in the same directory as build.scm and conf.scm)
;; You could also load tests/2/test but it will fail.
(use tests/1/test)

;; Compile a module (again, this has to be done from the right directory)
(use (build))
(module-compile! 'tests/1/test)


See tests/1/test.scm and tests/1/test2.scm for some clues about how to use the |use| macro. In its simplest form, it takes a symbol which in practise is a path to another .scm file (excluding the .scm suffix) relative to the current file, or pwd if in the REPL. The test-build.scm file is not very neat right now, but it contains a lot of tests for the hygienic system which might be useful to look at.

I guess that's it. Oh, the tarball can be found here:

http://mwaza.dyndns.org/apps/files/module.tar.gz

/Per