<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2013/11/8 Matthew Hastie <span dir="ltr"><<a href="mailto:matthastie@gmail.com" target="_blank">matthastie@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr">Marc,<div><br></div><div>I assume there is 1:1 correspondence between a prospective (preload-module foo) and a "x/y/z/foo.scm".</div><div><br></div><div>Do you have a plan for how you intend to map the preload-module identifier symbols to their corresponding pathed file name strings?</div>


</div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr">
<div>I foresee that <i>preload-module</i> can provide a syntax that is isomorphic to the chez scheme <i>visit,</i> 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.  </div>


</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.<br>


</div><div><br></div><div>Does the existing gsc command-line functionality continue to provide an implicit module load order in cases where the new syntax is not present?</div>
<div><br></div><div>Is there a reasonable behavior in the absence of <i>preload-module </i>syntax, or use cases where <i>preload-module</i> is partially provided by a subset of sources<i>?</i></div><div><br></div><div>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 <i>preload-module</i> 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.</div>


</div></blockquote><div><br></div><div>I guess this kind of questions will make custom module/macro/etc. system want to implement dependency handling itself, more or less from scratch?</div><div><br></div></div></div></div>