v6 Capstone: Full Pipeline

The final pipeline is Lex → Parse → Analyze → CompileModules → Link → Encode → Decode → NewVM().Run. v6 adds typed front-end contracts to the existing module/BC2/runtime path. Local variable annotations can be omitted when inference works; function signatures and exported-variable annotations are required. Do not require annotations on every local declaration.

Worked reconstruction

module math {
  export fn twice(x:number)->number { return x*2; }
}
module main {
  import math as m;
  let total:number=0;
  for (let i:number=0; i<3; i=i+1) { total=total+m.twice(i); }
  if (total!=6) { 1/0; }
}

Parsing builds both module and type trees. Analysis checks exports, argument and return compatibility, boolean loop conditions, and scope. Compilation uses the already established runtime instructions; it does not emit a second typed VM or serialize all Type trees into BC2. Link relocates later Main jumps and closure IDs; Decode rebuilds code before a fresh VM executes it. The assertion observes total=6; normal top-level completion returns nil.

Four distinct failure experiments

1. Remove a required function return arrow: parsing fails.
2. Pass true to twice: analysis rejects the argument type before execution.
3. Keep the types valid but divide by zero: runtime still fails.
4. Use nil in a number-annotated binding and add one: permissive nil assignability can allow analysis, while runtime arithmetic rejects nil.

A type checker is an implemented set of rules, not a slogan about eliminating all errors. Missing-return coverage, bounds, nil safety, and malicious bytecode verification are outside this educational checker. Preserve dynamic VM checks.

Final integration and transfer gate

Build your own two-module program using a returned closure, a collection, and a loop with continue. Save its token excerpt, AST/type outline, module export table, local-versus-linked address calculation, BC2 artifact, and runtime assertion. Introduce one fault at each representation boundary and explain the first observable difference. Re-run it with a fresh VM and link its artifacts twice to test isolation and input preservation.

You have finished the course route when you can implement the exercises, explain these artifacts without the reference open, and adapt one working program to a new requirement. Checkpoint scores help identify concepts to revisit; they are not a substitute for that independent construction.

Debugging lab

An accepted v6 program crashes when a number-returning function falls off its body. A proposed fix removes runtime type checks because the front end already checked the signature. Diagnose the mistaken guarantee.

Compare your diagnosis after attempting the lab

The checker validates explicit returns but does not prove every path returns, and nil is broadly assignable. Fallthrough produces nil at runtime. Keep VM checks; a stronger return-coverage or nil-safety system would require an explicit new analysis contract.

Transfer task

Extend the worked program to accept an array through an exported function and aggregate selected values. Give one statically rejected caller and one caller with correct types that fails bounds at runtime. Then propose, without changing the grader contract, what additional analysis would be needed to prevent the latter.

Carry forward

Keep the six-milestone portfolio as a reference for future language work. A next project can deliberately add precise capture resolution, stronger type guarantees, richer diagnostics, optimization, or native code generation, with new contracts and independent tests.

Build compile-and-run-v6. Keep a before/after trace of one failing test. Use the checkpoint to diagnose specific skills; passing it does not replace implementing and testing the artifact.