I just tried to figure out what the second argument of dynamic-require does when it&#39;s not a symbol, for the nth time.  First of all, the current interface -- 0, #false, and (void) as tokens for three rather arbitrary modes of operation -- leaves much to be desired.  These other modes should probably be other functions, or one other function with flags that are more mnemonic.<br>

<br>Second, the documentation of these modes is based on the technical terms &quot;instantiate&quot;, &quot;visit&quot;, and &quot;available&quot;, which I find incredibly arcane.  Even now that I have looked them up and know what they mean (I _think_), I don&#39;t know why these particular words were chosen for the concepts they represent.<br>

<br>To the best of my understanding, &quot;instantiate&quot; means &quot;allocate space for, and run, the relative-phase 0 content of a module&quot;; &quot;visit&quot; means the same thing at relative-phase 1.  Neither the terms nor their documented definitions actually indicate this close relationship; I had to puzzle it out to realize they are almost the same thing, essentially differing only by add1.  I would much prefer related terms, or even just one term used with a phase number.  Otherwise I&#39;m running around with two words for what seems to be just one concept.  I&#39;m also confused that there is no term for running module contents at higher phases.<br>

<br>The term &quot;available&quot; appears to mean &quot;queued up for on-demand instantiation&quot;.  Could we perhaps just say &quot;lazily instantiated&quot; here or something?  Again, the word &quot;available&quot; here doesn&#39;t really suggest what&#39;s going on to me.  Especially because to a user, the module doesn&#39;t actually become any more available than it was; it&#39;s only to the runtime implementation that the module suddenly becomes &quot;available&quot;.  And I don&#39;t think Matthew&#39;s C code reads the documentation very often.  (Though that would be impressive!)<br>

<br>Of course, if I&#39;ve interpreted these terms incorrectly, there&#39;s a further problem with either the explanation or my reading comprehension.<br><br>I can certainly understand how the documentation got to this state.  The module system is incredibly complicated, and at the outset I wouldn&#39;t know what to name anything, either.  And I would imagine dynamic-require&#39;s interface has evolved over time.  Now that we&#39;ve had it a while, though, I think we can do a lot to improve the clarity of these features.  I hope someone who understands them better than I do can take a stab at it.<br>

<br clear="all">Carl Eastlund<br>