Branch resolve-check (contains v3-generics-inc2, 19 commits back).
Design: docs/analysis_generics.md; inc2 record:
docs/summary_generics-inc2.md. Suite 196/196, incl.
GenericProg (single-formal Ident(INTEGER), exit 42).
ISO 10514-2 form: GENERIC DEFINITION/IMPLEMENTATION MODULE M(T :
TYPE) plus refinement DEFINITION MODULE X = M(actual). A refinement
instantiates by re-parsing the generic's source with the formals
bound to the actuals (SymTab.EnterTypeParamBound, Reenter; driver
registry maps generic name → file; the abstract template is never
emitted). Re-verified live: FROM IntId IMPORT Id; Id(42) → exit 42.
The "fresh finding" that a two-formal generic fails to link was my
incomplete test: I supplied only a definition refinement
(X = M(...)) and no implementation refinement
(IMPLEMENTATION MODULE X = M(...)), so the instance had no body to
emit (the single-formal tests always ship both g_intid.def and
g_intid.mod). With both refinements, Pair(T, U) instantiates
correctly, using both type parameters:
GENERIC DEFINITION MODULE Pair (T : TYPE; U : TYPE);
PROCEDURE First(x : T; y : U) : T;
PROCEDURE Second(x : T; y : U) : U;
END Pair.
DEFINITION/IMPLEMENTATION MODULE IntChar = Pair(INTEGER, CHAR);
First(7, "A") + ORD(Second(1, "B")) compiles, links and returns 73.
Locked as the suite test PairProg (g_pair.*, g_intchar.*,
g_pair_prog.mod). Suite 202/202.
Real (smaller) gap: if only the definition refinement is given, the module compiles clean but the link fails with no compile-time diagnostic. Worth a driver-level "refinement has a definition but no implementation" warning — not a correctness bug, a UX one.
GENERIC CLASS; generics with a program module.GENERIC CLASS; generics with a program module.cd .../m2compiler-V3/compiler
./M2 tests/g_ident.def tests/g_ident.mod tests/g_intid.def \
tests/g_intid.mod tests/g_prog.mod # GenericProg session
Multi-formal repro: rebuild /tmp/opencode/g2*.mod per §"Fresh
finding" above, then qbe + cc to observe the link failure.