Marc,
I assume there is 1:1 correspondence between a prospective (preload-module foo) and a "x/y/z/foo.scm".
Do you have a plan for how you intend to map the preload-module identifier symbols to their corresponding pathed file name strings?
I foresee that *preload-module* can provide a syntax that is isomorphic to the chez scheme *visit,* and it can thus provide better syntax-case integration. With preload-module, sources may be able to specify a dependency on compiled syntax across gambit modules, using a syntax that is native to gambit.
It is also great to see module loading order removed from the ordering of objects on the gsc command-line, which if I'm not mistaken is how it is done today.
Does the existing gsc command-line functionality continue to provide an implicit module load order in cases where the new syntax is not present?
Is there a reasonable behavior in the absence of *preload-module *syntax, or use cases where *preload-module* is partially provided by a subset of sources*?*
Do you anticipate modules with symmetric or symmetric transitive dependence? In such a use case, I'd presume load order is irrelevant providing that linkage is complete, but the issue of ordering top-level initialization may remain. This could be problematic for a proposed syntax case usage, as it is easy to specify symmetrically dependent compiled syntax between two files: if cyclic *preload-module* is not permitted, then syntax-case presumably needs a separate syntax to specify syntax dependency between files, if symmetrically imported syntax is a warranted feature.
On Wed, Nov 6, 2013 at 7:45 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
On Nov 6, 2013, at 3:03 AM, Álvaro Castro-Castilla < alvaro.castro.castilla@gmail.com> wrote:
It would be like a module system without the namespaces.
Yes, that's a way to put it.
Note that my proposal only aims to provide a very basic mechanism for loading in a VM modules of code with their dependencies. The "depends-on" form could of course be used for building a (slightly) higher-level module system to ensuring that module dependencies are satisfied. By the way, I think this form is probably best called preload-module, so that a program could be written like this:
(define (f n) (preload-module math) (+ (math:cbrt n) (math:fact n)))
(define (g x) (preload-module postscript) (preload-module math) (postscript:circle (math:square x)))
The code would be roughly equivalent to:
(if (not (loaded? 'math)) (load 'math)) (if (not (loaded? 'postscript)) (load 'postscript))
(define (f n) (+ (math:cbrt n) (math:fact n)))
(define (g x) (postscript:circle (math:square x)))
In other words, the requests to preload modules are just annotations that are accumulated for the whole module. The set of requests causes these modules to be loaded at the very beginning of the module's execution.
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.
I agree that a lightweight module system would be nice. This should be fairly simple to do once the linker is modified to support preload-module.
Marc
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list