You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Route mk_builtin and apply through the folding constructors
lambda.mli says a term can only be built through the constructors, seven of
which normalize as they build. That held for every client and not for the
module itself: mk_builtin and apply constructed Lprim directly, which they
could do only because they own the type.
mk_builtin is the path every builtin operator takes, so nothing folded at
production. [1. < (1. < 1. ? 1. : 10.)] left translation with both float
comparisons intact; it now folds to a constant. apply's eta reduction
substituted the arguments into the primitive call and left the result
unfolded, so [((a, b) => a + b)(1, 2)] became [(+ 1 2)] rather than [3]. apply
was defined above prim and could not call it; nothing between them refers to
apply, so it moves below.
The effect was invisible because the optimizer passes rebuild every node
through the constructors, and were folding this incidentally on the way past.
It showed up while measuring what a pass allocates when it changes nothing:
converting one pass to a sharing traversal made its output four nodes larger
on ppx_apply_test, which is the beta reduction above going unfolded.
Generated JavaScript is unchanged - the folding happened either way, just
later and repeatedly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W8g8qwBARAcvW9MyuKQq8H
0 commit comments