Multi-line let body wrapping in expand-let (eigentrust pitfall #5)

[kumavis]

Fixes pitfall #5 from the 2026-04-23 eigentrust pitfalls memo.

Summary

(let [tnew := [eigentrust-step c p alpha t]]
  match [rat-lt [linf-norm [sub-vec tnew t]] eps]
    | true  -> tnew
    | false -> [eigentrust-iterate c p alpha eps [int- budget 1] tnew])

failed with let: let with bracket bindings requires: (let [bindings…] body). The pitfall report attributed it to indent-handling. The actual root cause is different and instructive.

Root cause

let lives inside (...) parens. parse-reader's group-items applies its "brackets win" rule and DROPS indent-open / indent-close markers around the body. So (let [x := 1]\n match x | _ -> x) parses to (let (x := 1) match x $pipe _ -> x) — body tokens flat, length 7 instead of length 2 (bindings + body). The bracket-bindings branch in expand-let required exactly (length rest) = 2 and rejected anything else.

Fix

In expand-let branch 1 (bracket bindings), when (length rest) > 2, wrap the post-bindings tokens into a single body application. Localized, ~18 lines in macros.rkt. Avoids touching parse-reader.rkt's "brackets suppress indent" rule (which is intentional for non-let forms — we don't want (foo arg1\n arg2) to splice).

Why the suggested fix would have been wrong

The pitfall's "suggested fix" (align WS let parser with the indent rule that defn / match honour) misdiagnoses. defn / match work because they're at top-level (no enclosing parens), where indent grouping IS active. Inside (let ...), indent grouping is intentionally suppressed. The right fix is at the let macro, not at the parser.

Test plan

• New tests/test-let-multiline-ws.rkt — 11 cases: single-line baseline, multi-line with simple expression body, multi-line with nested match body (the eigentrust reproducer), edge cases
• Regression: 243 tests across 8 files (let-multiline, let-arrow, eq-let-surface, process-ws-01, parse-reader, multi-body-defn, match-builtins, pattern-defn) all green in 37.8s
• CI fix included (benchmarks/micro/info.rkt)

Commits

1. 4eb61d1 — primary fix in expand-let
2. c66a6d7 — CI fix (skip stale bench file)

https://claude.ai/code/session_01MbncYJnrvjzhbVWw4xGi5x

---

Generated by Claude Code

[kumavis]

hiero wants to review further

[kumavis]

crazy diff detected. @hierophantos should "cache" be in .gitignore ?

[hierophantos]

LGTM. Surgical 18-line fix in expand-let Branch 1 (bracket-bindings format). Replaces the strict (length rest) = 2 requirement with a cond that handles both the single-token body case ((cadr rest)) and the multi-token splice case ((cdr rest) wrapping post-bindings tokens as a body application).

Architectural discipline I appreciated: the PR explicitly debunks the "fix in parse-reader" hypothesis from the original pitfall report and explains why the parser-level fix would have been wrong — parse-reader's "brackets suppress indent" rule inside (...) parens is intentional for non-let forms (we don't want (foo arg1\n arg2) to splice). The macro-level fix is the architecturally-correct location.

Test coverage strategic (11 cases): regressions for single-line / single-token-continuation / bracket-grouped bodies; the eigentrust reproducer (nested match body); multi-binding case; error-case regression (let with bindings but no body still raises).

Audit: no test asserts the old "let with bracket bindings requires" error; multi-line (let [...] (let [...] ...)) patterns in examples/2026-03-16-track4-acceptance.prologos:625-626 would benefit from this fix.

Mergeable as-is, no conflicts.

Approving.