v6 Semantics: static types on a dynamic runtime

Trace expected types through declarations, calls, and returns.
Validate structural compatibility and exported signatures.
Distinguish actual checker behavior from stronger unimplemented guarantees.

1 / 6

Readiness

Build v6 Type trees and understand v5 module/export resolution.

2 / 6

Worked reconstruction

fn first(xs:array<number>)->number { return xs[0]; }
let values:array<number> = [];
let answer=first(values);

Expression/context	Information supplied	Result
annotated values initializer	expected array	empty literal receives that type
values used as argument	declared array	matches first's parameter
xs[0]	array element type number, numeric index	expression type number
explicit return	expected number	compatible
answer initializer	function return number	infer answer as number

The empty values array still makes first(values) fail at runtime. Type compatibility and bounds are different predicates.

3 / 6

Diagnose before implementing

A test expects xs=[] to inherit xs’s declared array type, and a lesson says every number-returning function must return on all paths. Which claims exceed this checker’s implementation?

4 / 6

Independent transfer

Write a typed exported function, call it correctly from a later module, then change only one argument type. Separately test wrong arity, an unknown export, and a correct type with an out-of-range array access; identify the earliest failure for each.

5 / 6

Carry forward

Carry an honestly bounded typed front end into the final capstone. Keep both rejected-static and accepted-runtime-failure examples as part of the course completion evidence.

6 / 6