Claude Code transcript

Now I see the problem. When parseIfStatement() encounters a nested IF token as a condition (line 2273), parseExpression(LOWEST) doesn't recognize IF as an expression, adds an error, returns nil without advancing the cursor. The main loop at line 2245 never makes progress - the token position doesn't change, creating the infinite loop.

In occam, nested IF within an IF block is a valid construct (a nested choice group or replicated IF), not a condition-body pair. Let me look at the AST to understand how to represent this:

Now let me understand the full picture. In occam, within an IF block you can have: 1. condition + body (normal choice) 2. IF i = 0 FOR n + choices (replicated IF - expands choices) 3. Nested IF + choices (nested IF block)

The current parser only handles case 1. Cases 2 and 3 are what cause the hang. Let me also check how parseStatement() handles the IF keyword to understand the complete flow:

Good. Now I have a clear picture. Let me plan the implementation:

Root cause: parseIfStatement() loop at line 2245 doesn't handle when curToken is IF (nested/replicated IF). parseExpression returns nil without advancing, and the loop has no progress guard, so it loops forever.

Fix strategy: 1. Add a NestedIf *IfStatement field to IfChoice for when a choice is actually a nested IF 2. In parseIfStatement, detect curToken == IF and recursively parse it 3. In codegen, handle nested IF: for non-replicated, inline the choices; for replicated, emit a loop with a _matched flag 4. Add a progress guard to the parseIfStatement loop as a safety net

Let me implement this:

Found the second infinite loop. In parseVariantReceive() (line 1214), the same problem: when COORDINATES (an unknown type treated as an IDENT) is encountered, it's read as a tag name (line 1248) but the cursor is never advanced past it. The main loop keeps re-parsing the same token.

Let me fix this by adding a progress guard:

Here's a summary of what was found and fixed:

Root Causes

Two distinct infinite loop bugs were identified:

1. Nested/Replicated IF within IF (parser.go:parseIfStatement)

When an IF keyword appeared as a choice inside another IF block (e.g., IF i = 0 FOR n used as a replicated choice), parseExpression(LOWEST) was called on the IF token. Since IF isn't a valid expression prefix, parseExpression returned nil without advancing the cursor. The main loop had no progress guard, so it re-parsed the same IF token forever.

Fix: Detect curToken == IF in the choices loop and recursively call parseIfStatement() to properly parse it as a nested IF. Store the result in a new NestedIf *IfStatement field on IfChoice. Also added a progress guard as a safety net.

2. Unknown types in variant receive (parser.go:parseVariantReceive)

When a variant ? CASE block contained declarations with unknown types (e.g., COORDINATES p: where COORDINATES is parsed as an IDENT), the parser treated it as a variant tag name but never advanced past it. The next iteration of the loop saw the same IDENT token and looped forever.

Fix: Added progress guards to both parseVariantReceive and parseVariantReceiveWithIndex. When no progress is detected, the parser forces advancement or breaks. Also changed the "unexpected tag" error path to skip the token with continue instead of returning immediately.

Changes Made