2013/11/8 Matthew Hastie matthastie@gmail.com
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?
That's what the hook is for - resolving a module identifier to an actual module, be it linked-in, in a file, module evaled from s-expression, etc.
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.
I guess this kind of questions will make custom module/macro/etc. system want to implement dependency handling itself, more or less from scratch?