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?