[gambit-list] chjmodule update

Christian christian at pflanze.mine.nu
Sat Jan 14 18:56:00 EST 2006


I've put up an updated version of chjmodule which works with beta
17. Basically nothing new except the necessary fixes.

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

- 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

- 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))

- 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.)


More information about the Gambit-list mailing list