It would be like a module system without the namespaces. I think that this is a very nice step, because it's an important part of the functionality of Blackhole or Schemespheres, but with the new features that you can implement at a lower level.
I'd actually like that this goes one step further an build a minimal module system (even if just select which variables to export per module). Such a simple module system (export / depends-on) would be very helpful for developing bigger applications with Gambit.

Best regards

On Tue, Nov 5, 2013 at 6:10 PM, Marc Feeley <feeley@iro.umontreal.ca> wrote:

Currently a Gambit executable program is a list of modules, with the "main" program as the last module. During the setup phase (function ___setup) these modules are initialized sequentially (as though they were "load"ed in turn). For example, the Gambit interpreter, gsi, consists of these modules ("_kernel" "_system" "_num" "_std" "_eval" "_io" "_nonstd" "_thread" "_repl" "_gsilib" "_gsi"). The module "_gsi" contains the code which starts the REPL.

This is fine in the context of a single Gambit VM instance per OS process. However, for the upcoming multithreaded Gambit, I want to support multiple VM instances per OS process, so the current linking model is not ideal. If the current linking model isn't changed, each VM instance will have to run the same program (requiring all VMs to initialize all the modules of the program), and the programmer will have to create custom logic in the "main" program to select the appropriate VM behaviour. This is clumsy.

So I'm considering changing the linker data structures to record module dependencies. Something like "before initializing module A, it is necessary to initialize modules B, C, and D". An executable program would thus be a set of modules with dependencies, and the name of the main module. The setup phase would do a depth first traversal of the dependency graph starting at the main module.

This would enable a few interesting features:

1) Allow the instantiation of a VM with a "main" module different from the other VMs, e.g. (start-new-vm "other-main").

2) Lazy initialization of modules (only the modules actually relevant to the main program need to be initialized).

3) Multiple modules could be bundled this way in a single executable program. The "load" procedure could be changed to lookup modules in the bundled set before going out to the file system to dynamically load a .o1 file. This would simplify the installation of multi-module applications and give better startup performance.

Note that for this to work, it will be necessary for the compiler to record module dependencies with each module and to output these dependencies in the linker data structures. A new special form, such as (depends-on <module>), will have to be added so that the programmer can express initialization dependencies in the source code. For consistency, the interpreter will also have to support this form.

Before going forward with this change, I would like to have some feedback. Do you see problems with this or suggestions?

Marc

_______________________________________________
Gambit-list mailing list
Gambit-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list