Module Identity

A module can export definitions and also execute top-level code that creates values or tracks. Its identity matters because importing a helper should not repeatedly rebuild those objects.

One session reuses unchanged source

A use resolves a file and obtains the session’s evaluated module. If neither that source nor anything it imports changed, the existing result is reused. Two aliases reaching the same module therefore do not mean two independent copies of its top-level state.

Saving a change to the module, or one of its dependencies, makes a later evaluation of use re-evaluate it. This is source-based reuse: re-running the import alone is not an instruction to start an unchanged module from scratch.

Each evaluation sees one version

Within one execution a module has one version, however often it is imported. A dependency reached through two import paths cannot change halfway through that execution because one import happens later. Circular imports are refused because neither side can finish constructing the exports the other needs.

Reloading source does not rewrite every value you previously derived from it. A pattern already sent to a track remains that pattern until you send its replacement. A closure or generator may also hold captured values. Re-evaluate the consuming lines when you want the new definitions to reach the music.

Reset starts a new module lifetime

RESET; clears the session’s modules as well as its variables and tracks. The next import evaluates the module afresh. Keeping reusable definitions in modules and the rig’s assembly in the main piece makes this rebuilding boundary easier to understand.

Modules specifies resolution and exports; Split a Piece into Modules shows an edit and reload.