v5 Modules: imports, exports, and a linker mindset

Explain imports/exports as dependency and visibility contracts.
Trace ordered module initialization without assuming source concatenation.
Separate v5 lexical syntax from later static type annotations.

1 / 6

Readiness

Complete the v4 integration gate and understand BC2 function IDs.

2 / 6

Worked reconstruction

module util {
  export fn add(a,b){ return a+b; }
  let hidden=99;
}
module main {
  import util as u;
  let result=u.add(2,3);
}

The parser creates two Modules, not one flattened statement list. util has one export and an internal binding. main records imported module name util with local alias u. The analyzer checks module order and export visibility. Each module compiles to its own initializer and locally numbered function table. The linker combines those artifacts; the VM runs util's initializer before main's so main can obtain the export map.

The module name identifies a compiled dependency; the alias is a binding local to the importing module. Renaming alias u to tools need not rename util or its function IDs. hidden exists inside util but cannot be accessed as u.hidden. These visibility rules are a language convention, not a security sandbox.

3 / 6

Diagnose before implementing

A learner changes import util as u to import util as tools and also renames util’s compiled module to tools. Explain why an alias change should not alter dependency identity.

4 / 6

Independent transfer

Draw the dependency and alias tables for modules base, middle importing base as b, and main importing middle as m. Mark an internal symbol that must remain inaccessible. Then tokenize an exported untyped v5 function.

5 / 6

Carry forward

Carry separate module identity, alias, and export lists into v5 parsing. Preserve earlier single-program tests through implicit main while adding explicit multi-module artifacts.

6 / 6