Summary

In let x = EXPR in BODY, the value expression is parsed with parse_expr_no_in() so the parser can distinguish the in keyword (separating value from body) from the in binary membership operator. This means membership tests in the value position require parentheses.

Example

// FAILS - parser treats first `in` as let...in keyword separator:
let present = k in s in present or not(present)
// WORKS - parentheses disambiguate:
let present = (k in s) in present or not(present)

Context

This is the remaining case where in is genuinely ambiguous. In quantifier/fix bodies (after :), in is unambiguously a binary operator and was fixed in 7ec1af7. But in let...in value position, both interpretations are syntactically valid.

Possible approaches

1. Status quo — require parentheses (documented behavior, simple)
2. Greedy parsing — parse the value with parse_expr() and use heuristics to find the let...in keyword boundary (fragile, complex)
3. Alternative syntax — use a different keyword for let body separation, e.g. let x = EXPR then BODY or let x = EXPR { BODY } (breaking change)

Option 1 is probably fine — it's a minor inconvenience and the error message could be improved to suggest parentheses.

🤖 Generated with Claude Code