@blerner thanks!

In dynamic-require, how can a module be instantiated but not visited? Is this possible only when the module is already available?

@shu—hung I’m not sure I understand the question. The dynamic-require function can instantiate a module without visiting it or making it available (where “available” is a lazy “visit”). So, dynamic-require is a core operation, and it’s the way that a module instance gets into that state.

Here is what I have in mind: - visit: triggered mostly by require when expanding (and compiling) a module; will execute programs in begin-for-syntax or higher - instantiation: evaluates the code in a module outside begin-for-syntax

Then it seems like even if we use dynamic-require to instantiate a module (either with #f or 0), the module could be visited if it is not already compiled / registered in the namespace. Is this correct?

An operation like require of dynamic-require works in two steps: resolve a module path, and then do something involving instantiation and visits. Resolution of a module path may have the side effect of causing a module to be declared, perhaps even by loading it from source — in which case, yes, an instance will be visited as part of expanding it to arrive at a module’s own declaration. That’s an instance of an instance of an ephemeral “module being expanded” module, though. After expansion and evaluation, the newly declared module starts out in a state with no instances and visits.

That clears up things! Thanks a lot

Right, I almost forgot about module loading from source triggered by module name resolving

@sanchom The source appears to be here https://github.com/mbutterick/pollen/blob/master/pollen/decode.rkt#L51-L70 At a quick glance the order they’re applied is a result of recursively walking the x-expr, and some procs obviously only apply to certain kinds of elements.