Summary

The PSLUA_runtime_lazy runtime fixture declared its state and val locals inside the forcing thunk (return function() local state = 0 ... end) rather than in the enclosing function(init) closure. Because a fresh state/val was created on every call to the thunk, the memoizing state machine never advanced past its initial state. All three of the fixture's jobs were dead code:

• The initializer re-ran on every reference to the lazy binding, instead of once.
• Each force returned a fresh value, so reference identity was not preserved (a correctness hazard for identity- or effect-bearing lazy values).
• An ill-founded cycle (a binding that forces itself during initialization) looped until the stack overflowed instead of raising the intended "X was needed before it finished initializing" error.

The fixture is emitted whenever the laziness transform falls back to a runtime lazy initializer, which happens for recursive binding groups it cannot statically order. It shows up in 13 of the golden outputs (typeclass-dictionary recursion), so real programs hit it.

The fix moves the two local declarations up one scope so they become upvalues of the returned thunk and persist across forces. The initializer now runs at most once.

I found this while reading CoreFn.Laziness to document it for #44; it is unrelated to the documentation work, so it ships on its own.

How it was verified

A new Lua.Run test runs the actual fixture through lua: it builds a lazy value whose initializer bumps a counter, forces it twice, and exits 0 only if the counter is 1. The test was red before the fix (exit 1, initializer ran twice) and is green after. The 13 affected golden.lua files change only by the two-line move; golden.ir is untouched (the fixture is a codegen-level artifact).

Checklist

• Added a changelog.d/ fragment for any user-facing change (scriv create
  in the dev shell), or this change ships nothing releasable (CI, docs, or an
  internal refactor).
• In the dev shell (nix develop), fourmolu -i lib/ exe/ test/ and
  hlint lib/ exe/ test/ are clean.
• In the dev shell, cabal test all passes; structural goldens were
  re-accepted on purpose because codegen moved (PSLUA_GOLDEN_ACCEPT=1), and
  eval/golden.txt still holds.