[gambit-list] Gambit linking

Álvaro Castro-Castilla alvaro.castro.castilla at gmail.com
Wed Nov 6 03:03:45 EST 2013

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 at 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 at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131106/cf605db5/attachment.htm>

More information about the Gambit-list mailing list