v5 Semantics: import/export resolution

Validate dependency order, aliases, and export visibility.
Distinguish v5 name/module checking from v6 static typing.
Predict diagnostic order at module and expression boundaries.

1 / 6

Readiness

Build v5 module ASTs and retain declared-before-use/loop rules.

2 / 6

Worked reconstruction

module util {
  export fn id(x){ return x; }
  fn hidden(){ return 7; }
}
module main {
  import util as u;
  let a=u.id(3);
  let b=u.hidden();
}

Build the module-name index: util→0, main→1. Gather util's exported name id. In main, import util is valid because 0<1 and binds alias u. For u.id, resolve u→util then check id in util's export set. u.hidden fails with unknown export even though hidden has a valid internal declaration. No numeric type property of id's argument has been established.

3 / 6

Diagnose before implementing

A lesson predicts a static number/bool error for u.id(true) in v5, and a test places main before util while demanding only unknown-export. What unstated assumptions caused both errors?

4 / 6

Independent transfer

Construct three otherwise valid programs that separately fail for unknown import, future import with main still last, and missing export. Record the earliest diagnostic and identify which table lookup produces it.

5 / 6

Carry forward

Carry an accepted module graph into CompileModules. Acceptance proves the stated name/order rules, not type correctness or runtime success.

6 / 6