Problem
Across the package-set forks, several latent performance and output-size concerns need auditing: Lua-specific foreigns declared in curried a -> b -> Effect c shapes (which compile to closure chains rather than direct calls), hot string operations that may concatenate with .. in recursion instead of accumulating, and dead PureScript-side *Fallback functions that the linker retains in output. Both audit streams are only meaningful once the compiler series makes them so, hence they are scheduled rather than immediate.
Approach
Two audit streams:
1. Uncurried shapes (after #179). Public fork APIs cannot change (they must stay API-compatible with the registry packages), so the scope is narrow: (a) Lua-specific foreigns that do not exist upstream and use curried a -> b -> Effect c shapes where an EffectFn2 would compile to a direct call once #179 lands; (b) verify the arity of every .lua implementation against the upstream Fn/EffectFn/STFn declaration it backs. Historical context that this machinery is live and error-prone: #57 (runEffectFn10 dropped its tenth argument).
2. String accumulation and fallback coverage. Verify hot string operations accumulate via table.concat rather than .. in recursion. Also map fallback coverage: the PureScript-side *Fallback functions (takeFallback, singletonFallback, codePointAtFallback, …) are dead in practice in the Lua forks — the foreigns implement the operations natively and ignore the fallback argument — yet they stay in linked output, because DCE cannot drop an argument to an opaque foreign call.
Prerequisites / Relations
Stream 1 depends on #179: before it lands, EffectFn compiles to the same closure count as curried FFI, so the audit would be pointless. #172 provides the benchmark harness that lets each finding be defended with a number. #185's constructor-representation fork audit can be scheduled into the same pass if the timing aligns. Otherwise this is package-set-level work, independent of the compiler-side issues.
Verification / Measurement
The audit produces two concrete artefacts: (1) a list of Lua-specific curried foreigns convertible to EffectFn/Fn shapes, plus confirmed-correct arity for every .lua implementation against its upstream declaration; and (2) a per-fork map of live vs. dead fallbacks, answering both "where could quadratic concatenation ever run" (only where a fallback is live) and "how much dead fallback code the linker retains" (an output-size observation for the compiler side). There is no standalone speed-up number for the audit itself.
Problem
Across the package-set forks, several latent performance and output-size concerns need auditing: Lua-specific foreigns declared in curried
a -> b -> Effect cshapes (which compile to closure chains rather than direct calls), hot string operations that may concatenate with..in recursion instead of accumulating, and dead PureScript-side*Fallbackfunctions that the linker retains in output. Both audit streams are only meaningful once the compiler series makes them so, hence they are scheduled rather than immediate.Approach
Two audit streams:
1. Uncurried shapes (after #179). Public fork APIs cannot change (they must stay API-compatible with the registry packages), so the scope is narrow: (a) Lua-specific foreigns that do not exist upstream and use curried
a -> b -> Effect cshapes where anEffectFn2would compile to a direct call once #179 lands; (b) verify the arity of every.luaimplementation against the upstreamFn/EffectFn/STFndeclaration it backs. Historical context that this machinery is live and error-prone: #57 (runEffectFn10dropped its tenth argument).2. String accumulation and fallback coverage. Verify hot string operations accumulate via
table.concatrather than..in recursion. Also map fallback coverage: the PureScript-side*Fallbackfunctions (takeFallback,singletonFallback,codePointAtFallback, …) are dead in practice in the Lua forks — the foreigns implement the operations natively and ignore the fallback argument — yet they stay in linked output, because DCE cannot drop an argument to an opaque foreign call.Prerequisites / Relations
Stream 1 depends on #179: before it lands,
EffectFncompiles to the same closure count as curried FFI, so the audit would be pointless. #172 provides the benchmark harness that lets each finding be defended with a number. #185's constructor-representation fork audit can be scheduled into the same pass if the timing aligns. Otherwise this is package-set-level work, independent of the compiler-side issues.Verification / Measurement
The audit produces two concrete artefacts: (1) a list of Lua-specific curried foreigns convertible to
EffectFn/Fnshapes, plus confirmed-correct arity for every.luaimplementation against its upstream declaration; and (2) a per-fork map of live vs. dead fallbacks, answering both "where could quadratic concatenation ever run" (only where a fallback is live) and "how much dead fallback code the linker retains" (an output-size observation for the compiler side). There is no standalone speed-up number for the audit itself.