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
I think the most interesting part of tail recursion/tail calls is not actually tearing down the stack frame early, but rather decrementing the reference counts on local variables early, in order to reduce space consumption and enable more in-placing. And decrefing can happen much earlier than the final call in a definition. E.G. this should be able to work in place:
f=. {{ 1 (2}) y }}
g=. {{
a=. i.y
b=. f a
b }}
g 1e8
Activity
moon-chilled commentedon Apr 16, 2022
I think the most interesting part of tail recursion/tail calls is not actually tearing down the stack frame early, but rather decrementing the reference counts on local variables early, in order to reduce space consumption and enable more in-placing. And decrefing can happen much earlier than the final call in a definition. E.G. this should be able to work in place:
moon-chilled commentedon Apr 16, 2022
(also: of course should be togglable, though probably orthogonal to debug mode, as you might want to include debugging without giving up performance)
HenryHRich commentedon Mar 29, 2026
This should be done by explicit user action. Perhaps a keyword recur. which is 'goto_0' but clearing local variables and setting new x/y.