Lower self-recursive tail calls to while loops (loopification) - #205

Closes #181.

What

A self-recursive tail call now lowers to a while true do loop with simultaneous multiple assignment of the parameters. return go$w(e1, e2) in tail position becomes p1, p2 = e1, e2 followed by fall-through to the end of the loop body; every other exit path keeps its return, which leaves the loop.

The transform lives in the Lua code generator (new module Language.PureScript.Backend.Lua.Loopify), applied to recursive-group bindings at the two places they are lowered: top-level groups (self-reference through the M table) and Let-bound groups (plain local). The expression IR keeps no loop node, the same choice magicDo makes for statements. Foreign code never passes through it.

Tail positions are found by walking the block spine of the generated function: the final statement of the body and, recursively, the final statement of each branch of a block-final if. This is exactly where the code generator puts IR tail positions (through Let bodies and IfThenElse branches), and it is what makes fall-through work as "continue" on a target without goto.

Two things fell out beyond the issue text:

• Plain unary self-recursions loopify too, without needing a worker/wrapper split: countdown n = ... countdown (n - 1), and structural recursions like bat (Succ n) = bat n (which becomes n = n.value0).
• Only the tail self-calls need rewriting. Non-tail self-calls and the wrapper indirection stay real calls, each starting a fresh activation with its own loop. McCarthy 91 in the golden shows both in one body.

Correctness guards

Capture veto. Lua closures capture variables by reference, and parameters of a loopified function are shared across iterations, so a closure created in one iteration and surviving into the next would observe the reassigned values. A body that references a parameter from inside a nested function literal is therefore not loopified. Immediately-invoked scope wrappers (function() ... end)() are looked through transparently; without that, the comparison predicates the case compiler emits (IIFEs reading the scrutinee) would veto nearly everything. The golden's CPS accumulator (sumCPS n k = ... sumCPS (n - 1) (\r -> k (r + n))) pins the veto: it stays recursive, and the hand-written eval oracle would catch the corruption if it ever loopified.

Explist balancing. The assignment's right-hand explist is balanced to the variable count, because the code generator drops trailing unused parameters and trailing Prim.undefined arguments, so the two lists can disagree in length. A short list is padded with explicit nils (declined when the last argument is a call or vararg, whose multiple results the pad would truncate where the call form spreads them); surplus expressions facing dropped parameters are removed when syntactically pure, and decline the rewrite otherwise. This also keeps luacheck's unbalanced-assignment check quiet.

Tests

• New golden Golden.Loopification.Test with six shapes (unary countdown, binary accumulator, local where-bound worker, McCarthy 91, CPS capture veto, dead trailing parameter) and a hand-written eval oracle.
• Nine unit tests in Lua.Spec cover the decision points through fromUberModule: top-level and Let-bound groups, non-tail calls, the capture veto, and all four explist-balancing outcomes.
• Four existing goldens moved: Uncurry (the sumTo worker), LongCallbackChain, PatternMatching.Test2, and StringCodePoints (the library's codePointAtFallback worker loopifies). golden.ir files are untouched, since the transform is strictly Lua-side. All eval oracles pass unchanged.

Measurements

On curried_step (n=2e6, medians): PUC Lua 0.363s to 0.348s, the modest constant-factor win the issue predicted, since the loop body is still dominated by curried FFI closure allocation. Under LuaJIT the loop is blacklisted (IFUNCF to ILOOP in the accepted trace report) because those same per-iteration FNEWs abort trace recording, and the benchmark regresses from 0.196s to 0.366s for now. That interim regression should flip once #178/#180/#186 remove the allocations from loop bodies; it is tracked in #204.