On Nov 7, 2013, at 10:32 AM, Mikael mikael.rcv@gmail.com wrote:
|preload-module| builtin dependency handling logics can work out real well.
I'm asking myself if that logic needs to be there though -
I understand that Gambit's builtin modules require a particular order of introduction into the GVM, however that order is hardcoded today isn't it, so can't that just remain so;
I'm not sure what you mean by "hardcoded order". When the Gambit linker is called to create the link file for the Gambit runtime library, the list of modules of the runtime library is passed to the linker (just like when linking an application) and the linker creates an array of module descriptors that will be iterated over to initialize each runtime library module.
Would the additional complexity of |preload-modules| really be worth it, considering that it works well for Gambit's built-in modules to have a hardcoded load order -could that be 15 lines of code- , and as soon as Gambit is running fully, it delivers well anyhow that the user does dependency loading programmatically instead of having that done by additional logics in Gambit and a new special form?
When the Gambit interpreter is built, the main module of the interpreter, "_gsi", is added to the array of module descriptors by the linker. This module is in charge of handling command-line options and starting a REPL. So this module is initialized in addition to the modules of the runtime library, and it is this initialization that starts the interpreter's REPL. Gambit's initialization code doesn't distinguish between the modules that are part of the runtime system and the modules of the application. Indeed, it is even possible to create a library that extends the base runtime library, and use this extended runtime library to link applications. The only module with a special status is "_kernel", because it contains essential procedures (such as the code that builds rest parameter lists). I can imagine scenarios where some programs may not need the modules "_eval" and "_repl" (implementing the interpreter and REPL), so it is wrong to make them "builtin" for all programs.
So, in a Gambit supporting multiple VMs, what should happen when the main VM starts a new VM? It would be wrong to automatically start a new REPL just because the main VM also started a REPL. To achieve this, we'd have to add to the end of "_gsi" some program logic like this:
(if (main-vm? (current-vm)) (start-REPL))
This clumsiness is due to the fact that the VM creation operation isn't explicit about what modules that VM should load. It is also a performance problem if the main VM has many modules, most of which are irrelevant to the new VM's behavior.
Marc