Now update parseStatement() to handle the fact that parseAbbreviation() now returns ast.Statement (was *ast.Abbreviation):

The call site is already return p.parseAbbreviation() which returns an ast.Statement now, so the parseStatement switch is fine. But let me verify the return type change doesn't break anything:

Now I also need to update the infix expression loop to continue past NEWLINEs when there's a pending operator. The issue is the infix loop currently stops at NEWLINE:

for !p.peekTokenIs(lexer.NEWLINE) && !p.peekTokenIs(lexer.EOF) && precedence < p.peekPrecedence() {

This is correct for the normal case — the NEWLINE stops parsing. But the parseBinaryExpr already handles the case where the operator is at end-of-line and the RHS is on the next line. The real question is: in the expression (direction = exact) AND\n (...), the AND is at end of line, and the parser reads the AND token. Then parseBinaryExpr gets called, which moves past AND to NEWLINE, sees the NEWLINE+INDENT, and skips them to get the RHS. That should work.

But wait — looking at the infix loop more carefully, if peekToken is NEWLINE, the loop stops. So when we have expr AND\n, the peek token after the infix operator AND would NOT be NEWLINE because AND hasn't been consumed yet. Let me trace through:

1. parseExpression() sees expr as left
2. The infix loop checks peekToken — which would be AND (not NEWLINE)
3. It enters the switch, calls parseBinaryExpr(left)
4. In parseBinaryExpr, curToken is AND, we do p.nextToken() — now curToken is NEWLINE
5. Our new code skips NEWLINE/INDENT tokens
6. Works correctly!

But there's a subtlety: after parseBinaryExpr returns, the infix loop continues. The issue is for chained operators like expr OR\n expr AND\n expr. After parsing the first OR+RHS, the peek might be NEWLINE. Let me check... Actually, the right-hand expression in parseBinaryExpr calls parseExpression(prec) which will parse the inner expression. The inner call to parseExpression will see expr AND\n expr and handle it recursively because AND has higher precedence.

Let me build and test this compiles.

Let me reconsider my approach for multi-line expressions. The parseBinaryExpr approach has issues with INDENT tracking. A better approach is to handle continuation at the lexer level, similar to paren suppression. Let me revert the parseBinaryExpr change and implement lexer-level continuation instead.

Good — the intrinsics are being generated as-is (called as Go functions). I need to: 1. Emit them as _LONGPROD(...) etc. (prefixed with _) 2. Add the helper function implementations 3. Handle ArrayLiteral in expression generation 4. Handle RetypesDecl in statement generation 5. Handle CAUSEERROR() → panic("CAUSEERROR") 6. Handle untyped VAL abbreviations at package level

Let me also check the RETYPES lines.

The issue is: X is already declared as a float32 parameter, and we're trying to do X := int(...) which would try to declare a new variable with the same name. In Go, := in a function body CAN shadow a parameter, but the error is actually about type — it says "cannot use int as float32 value in assignment". Wait, that's odd for :=.

Actually, looking more carefully at the error: cannot use int(int32(math.Float32bits(float32(X)))) (value of type int) as float32 value in assignment. This suggests Go sees this as an = assignment (not :=). Let me check — in Go, if the variable is already declared in the same scope, := becomes =. Since X is a parameter in the same scope, Go treats X := int(...) as just X = int(...), which is a type mismatch.

The fix: use a different variable name for the RETYPES result. In occam, RETYPES creates a new alias, so we should use a distinct name. But wait — in the occam code, the NEW X (the int) shadows the OLD X (the float32). All subsequent code uses X as an int.

The cleanest approach: create a temporary for the old value, then shadow with a new variable.

The problem is clear: X is a float32 parameter, and X := _retmp13 tries to declare a new X of type int (from the temp), but Go sees it as trying to assign _retmp13 (int) to the existing X (float32). The := actually creates a new shadowing variable, so the real issue is that Go vet detects the type incompatibility at the declaration point — wait, actually X := should create a new variable shadowing the parameter. Let me check more carefully what Go does here.

Actually, the issue is that := in a function body does create a new variable. The error message says "cannot use _retmp13 (variable of type int) as float32 value in assignment." This suggests Go is treating it as an assignment to the existing X float32. But := should create a new variable...

Let me check — maybe it's because of some Go rule about := when the same name exists in the same scope (not just outer scope).

Line 356: PROC Round (INT Xexp, Xfrac, Xint, direction) — all INT parameters, not VAL, so they're all reference params. The call is Round (Xexp, Xfrac, Xint, round.direction).

In the generated Go, Round expects (*int, *int, *int, *int) and the call should pass &Xexp, &Xfrac, &Xint, &round_direction. The issue is that Xfrac and Xint are being passed without & on line 1642.

This is a proc call argument generation issue — the codegen needs to know that these are non-VAL params and wrap them with &. Let me check how generateProcCall handles this.

So Round is generated correctly as a closure. Now the call Round(&Xexp, Xfrac, Xint, &round_direction) — the issue is Xfrac and Xint are not being prefixed with &.

Since Round is a nested proc defined as a closure, its signature was registered in procSigs during collectNestedProcSigs of the parent proc's body. But perhaps the signature was registered with the occam name Round while the lookup uses a different name? Let me check.

Round(&Xexp, Xfrac, Xint, &round_direction) — Xexp and round_direction get & but Xfrac and Xint don't. Let me check the occam signature:

PROC Round (INT Xexp, Xfrac, Xint, direction) — this is the shared-type pattern where all 4 params share the INT type, all non-VAL. So they should all be *int.

The issue might be in how the parser handles shared-type params in nested procs. Let me add some debug output to understand.

The problem is a name collision! There are TWO nested Round procs with different signatures — one inside REAL32TOSTRING and one inside REAL64TOSTRING. The first pass's collectNestedProcSigs puts both into a flat map, so the second overwrites the first. I need to register nested proc signatures locally when entering each proc scope.

Good — the RETYPES rename is working correctly (_rp_X parameter, X := new variable). The remaining MaxInt declared-not-used issue is from the occam source — it's a constant declared but never referenced. This is a general issue with how we generate _ = var suppression statements.

Let me check if we already generate _ = var for local abbreviations.

I see — line 1981: Zfrac := make([]int, 2). The [2]INT Zfrac: declaration in the REAL64 version is generated as a Go slice, but RealIMul expects [2]int (a fixed-size array).

This is a broader issue: the [2]INT declarations in function bodies are generated as make([]int, 2) (slices) but function parameters with [2]INT are [2]int or *[2]int (arrays). Let me check how [2]INT var declarations are generated.

The occam code is RealIMul(Zfrac, [PowerTenFrac FROM (S+S) FOR 2]). The slice [FROM ... FOR 2] produces a []int, but the function expects [2]int.

The cleanest solution: change RealIMul (and similar) to accept []int instead of [2]int. But the proc definition says [2]INT which generates as a fixed-size array.

Actually, the better approach: for proc parameters, when they're VAL fixed-size arrays, generate them as slices rather than arrays. That way both fixed arrays and slices can be passed. Let me think about this more carefully.

Actually, the simplest targeted fix: when generating a function call and the param expects a fixed-size array but the argument is a slice expression, wrap it with a conversion. But we don't have type info in codegen.

The pragmatic fix: change [2]INT proc params to use Go slices. In occam, [2]INT params and []INT open-array params are semantically different (one knows the size, one doesn't), but in Go we can use slices for both.

The issue is *Xfrac[1] — Xfrac is now []int (a slice param), not *[2]int. The * dereference is wrong. The codegen is treating Xfrac as a pointer param and adding * for assignments, but since we changed fixed-size array params to slices, the * is wrong.

The root issue: when a non-VAL [2]INT Xfrac param is now []int, the codegen's refParams tracking still marks it as a reference param and adds * for reads/writes. Since slices are already reference types, I need to exclude fixed-size array params from refParams.

Line 1521: non-VAL params without channel/open-array status are registered as reference params. Fixed-size arrays (p.ArraySize != "") are included here because the condition doesn't exclude them. Since we changed fixed-size array params to slices, they shouldn't be treated as reference params (no * dereference needed).

The issue: a param named byte conflicts with Go's built-in byte type. The param byte *byte shadows the built-in byte type, so byte(...) tries to call the *byte variable instead of a type conversion.

This is a name collision with Go keywords/builtins. The occam source uses byte as a variable name, which clashes with Go's byte type. Let me check the occam source.

The occam proc has BYTE byte — a param named byte of type BYTE. In Go, byte is a built-in type, so using it as a variable name causes confusion when you also need byte(...) type conversion.

The fix: the goIdent() function should rename identifiers that conflict with Go keywords/builtins. Let me add byte to the set of reserved words that get renamed.

All 13 new tests pass: - 5 parser tests: untyped VAL, array literal, RETYPES, RETYPES array, multi-line boolean - 4 codegen tests: array literal, untyped VAL, CAUSEERROR, Go reserved word escaping - 4 e2e tests: untyped VAL, array literal indexing, multi-line boolean IF, CAUSEERROR panic

Let me now update the task status and update the documentation.

All tests pass. Here's a summary of everything implemented in Phase 2:

Phase 2 Complete: Full Course Module Transpilation

The full course.module (including float_io.occ) now transpiles with 0 parse errors and passes go vet.

What was implemented

Lexer changes: - [/] bracket NEWLINE suppression (parenDepth tracking) - RETYPES keyword token - Multi-line expression continuation (lexer-level isContinuationOp() + lastTokenType tracking)

AST additions: - ArrayLiteral (Expression) — [1, 2, 3] - RetypesDecl (Statement) — VAL INT X RETYPES X :

Parser changes: - Untyped VAL abbreviations (VAL name IS expr :) - Array literal expressions ([e1, e2, ...]) - RETYPES declarations (single and array forms)

Codegen changes: - Array literal generation ([]int{...}) - Untyped VAL (var x = expr) - RETYPES with parameter renaming to handle same-name shadowing - 7 transputer intrinsic helper functions (LONGPROD, LONGDIV, LONGSUM, LONGDIFF, NORMALISE, SHIFTRIGHT, SHIFTLEFT) - CAUSEERROR → panic("CAUSEERROR") - Go reserved word escaping in goIdent() (byte → _byte, etc.) - Scoped nested proc signature collection (fixes same-named procs in different scopes) - Abbreviation _ = name suppression in function bodies - Fixed-size array params mapped to slices for Go compatibility

Tests added: 13 new tests

• 5 parser unit tests
• 4 codegen unit tests
• 4 e2e tests (including CAUSEERROR panic verification)