Hello

I've put up an updated version of chjmodule which works with beta 17. Basically nothing new except the necessary fixes. http://scheme.mine.nu/gambit/chjmodule/

About the future: I'm short on time, but I've got a bunch of ideas to try with chjmodule. I'll get back at them slowly but probably steadily.

- use the c#expand-source hook instead of writing temporary files for adding the necessary namespace magic to the source. Actually I'm thinking about also providing a new source expander, which allows a version of define-macro that may handle source location annotations.

- solve the problems with the import speed and with the compiler optimizations: instead of letting the loader transfer bindings, let the client module do that itself: prepend this for each binding to the code of the client module (by use of the expander hook): (define car (let () (##namespace ("")) car)) (define rest (let () (##namespace ("")) cdr)) (define sxml-foo (let () (##namespace ("sxml#")) foo)) etc.

- declarations (declare ..) shall be put into the -module.scm files.

- binary-versioning of code: a module shall be rebuilt if an object file has been compiled for a different gambit release than the currently running (since otherwise they may crash the scheme system upon loading). Thus: put object and .c files into subdirectories which contain the gambit version.

(- versioning of code in memory: I'm thinking of keeping separate versions of code in the same scheme system process: e.g. one on which one is debugging (for example interpreted), another one which is used live (for example compiled), using separate namespaces for each.)

- specializing: I've got an idea of "merge" module files, which create a new specially compiled module from existing ones: Given a module F which, by default, depends on functions and macros from modules D and E. Now there's a merge module file which defines a module F' which depends on functions and macros from modules E and G, replacing the functionality originally provided by module D with the one provided by module G. Example: srfi-1 defines many list processing functions. I want to change the srfi-1 code to use |delay| in the right positions to make them output streams. But by default, the |delay| syntax would be a noop defined in module D. And by default, it would take |car|,|cdr| etc. from module E (which in that case would actually be from namespace "", the gambit builtins). But then I would define a merge module named srfi-1-stream, which takes the exact same srfi-1 module, but replaces the dependency D with G which defines |delay| to be the gambit builtin one, and it replaces the dependency E with one named H which defines |car|, |cdr| etc. to be functions which |force| their argument, so that the functions can also take streams as inputs. Then one could also write a module merge file named srfi-1-syntax, which redefines |car|,|cdr| etc. to be operations which operate on syntax trees carrying source location annotations (well, probably that one won't be so easy if the aim is to carry over as much location information to the output as possible).

Ok I'm sure this one is an old idea. I've never really looked at the SML or S48 module systems, is this how they work? Does the R6RS module system (aim to) provide this?

- possibly work with/on the object system (CLOS-like, with MI) which has been started by Ken Dickey, and think about integration with the module system. (Probably easy as long as only one global place for generics exists.)

Christian.