Claude Code transcript

Yes, that makes complete sense. During debugging I was essentially writing mini integration tests on the fly — small occam programs targeting specific constructs, running them through the transpiler, and checking that the output compiled and produced correct results. Those are exactly the kind of tests that should be captured permanently in the test suite.

Let me take a quick look at what's currently covered so I can give you a concrete picture of where the gaps are.

That's a thorough analysis. Here's the summary:

Current state: ~124 e2e tests, ~49 codegen unit tests, ~80 parser tests, ~9 lexer tests, ~22 preprocessor tests.

Biggest gaps with zero or near-zero test coverage:

1. Transputer intrinsics (LONGPROD, LONGDIV, LONGSUM, etc.) — zero tests at any level
2. RETYPES — parser tests only, no codegen/e2e verification that bit-reinterpretation actually works
3. RESULT qualifier on proc params — completely untested
4. Fixed-size array params [n]TYPE → pointer — completely untested
5. Shared-type channel params PROC f(CHAN INT a?, b?) — completely untested
6. VAL []BYTE s IS "hi": abbreviation — completely untested
7. ALT with boolean guards — parser test only, no e2e
8. MOSTNEG/MOSTPOS for REAL32/REAL64 — codegen unit only, no e2e
9. Modulo operator \ — lexer tokenization only
10. print.string / print.newline — no e2e execution

Partially covered features include STOP (only the "not taken" path), lexer paren-depth suppression (only exercised indirectly), and string-to-[]byte wrapping.

So yes — I could write a substantial batch of new tests covering all of these gaps. The e2e tests are the highest-value ones since they verify the full pipeline (parse → codegen → compile → run → check output). Want me to go ahead and write them? I could tackle them as a batch, or focus on specific areas you care about most.

Three failures to fix:

1. TestAllKeywords - the input doesn't end with \n properly (the NEWLINE is consumed as part of the continuation of OR). Let me check.

Actually, the OR at the end is a continuation operator, so the newline after OR gets suppressed. Let me reorder to put OR not at the end.

1. TestStringEscapeSequences - escape processing happens in the parser, not the lexer. The lexer preserves the raw *n.

2. TestByteLiteralEscapeToken - same issue, escape processing is in the parser.

Let me fix these.

Two intrinsic test failures — my expected values were wrong. Let me fix them.

For TestE2E_LONGPROD: 100000 * 100000 = 10,000,000,000. On a 64-bit system, int is 64-bit, but the intrinsics use uint32 casting. Let me recalculate.

Actually the issue is that 100000 doesn't fit in a uint32 as expected — wait, 100000 is well within uint32 range. Let me recalculate: uint32(100000) * uint32(100000) = 10,000,000,000. In uint64: 10000000000 = 0x2_540B_E400. hi = int(int32(uint32(0x2))) = 2, lo = int(int32(uint32(0x540BE400))) = int(int32(1409286144)) = 1409286144.

But the actual output is 1410065408. Let me check... Actually 100000 in occam might be parsed as a Go int which is 64-bit. The LONGPROD casts to uint32(a) first. uint32(100000) = 100000. uint64(100000) * uint64(100000) = 10000000000. 10000000000 in hex is 0x254_0BE_400. uint32(10000000000 >> 32) = uint32(2) = 2. uint32(10000000000) = uint32(0x540BE400) = 1409286144.

Hmm, but we're getting 1410065408 = 0x54000000. That's different. Let me actually compute what the Go code does.

Actually wait — the issue might be that 100000 is being treated differently. Let me just run a quick check to verify what LONGPROD actually produces.

All done. Here's what was added:

New Test Files

codegen/e2e_intrinsics_test.go — 13 tests

Transputer intrinsics (previously zero coverage): - LONGPROD (basic + with carry) - LONGDIV (basic + large roundtrip with LONGPROD) - LONGSUM (basic + overflow) - LONGDIFF (basic + borrow) - NORMALISE (basic + zero) - SHIFTRIGHT, SHIFTLEFT (basic + cross-word shift)

codegen/e2e_retypes_test.go — 6 tests

RETYPES bit reinterpretation (previously parser-only): - float32→int (1.0, 0.0, -1.0) - Same-name shadowing (VAL INT X RETYPES X :) - float64→int pair (1.0, 0.0)

codegen/e2e_params_test.go — 6 tests

Proc parameter variants (previously zero coverage): - RESULT qualifier (single + multiple) - Fixed-size array params [2]INT - Shared-type channel params CHAN OF INT input?, output! - Shared-type int params VAL INT a, b - VAL []BYTE param with string→[]byte wrapping

codegen/e2e_strings_test.go — 5 tests

String/print operations (previously zero e2e): - VAL []BYTE s IS "hello": abbreviation - print.string - print.newline - Combined string printing - String with escape sequences

codegen/e2e_misc_test.go — 24 tests

Coverage for many smaller gaps: - SKIP (standalone + in PAR) - STOP (reached — verifies deadlock/non-zero exit) - Modulo operator \ (basic + in expression) - ALT with boolean guards (FALSE guard + TRUE guard) - MOSTNEG/MOSTPOS for REAL32 and REAL64 (4 tests) - Shorthand slice [arr FOR m] - String→[]byte wrapping - Go reserved word escaping (len, byte) - Multi-line expressions (continuation + paren) - Negative int literal, NOT, AND/OR - Nested IF, WHILE loop, CASE multi-arm - = / <> operators - STOP in proc (compile-only check) - Nested replicated SEQ - Array slice assignment - Function call in IF condition - Recursive function - Multi-line proc params - go vet cleanness check

lexer/lexer_test2_test.go — 15 tests

Lexer-level coverage gaps: - All 33+ keywords (previously only 11 tested) - Paren depth suppression of INDENT/DEDENT - Bracket depth suppression - Continuation operator line continuation (+ AND) - String literal tokenization - String escape preservation - Byte literal + escape - Send/receive !/? tokens - Ampersand & token - Semicolon ; token - Nested paren depth tracking - Mixed paren/bracket depth - Line/column tracking

Summary

All 69 new tests pass alongside all existing tests.