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
However, I was doing some testing myself, and I found that the tail call version of length() still hits Maximum call stack size exceeded at ~ 8,400 item long arrays on my Macbook Pro
Is this because of the inefficiency of [first, ...rest]. My understanding of the article was that the recursion was now ok because JavaScript optimizes away the function call overhead and stack space.
I'm just finding both the tail call length and the inefficient one fall over at the same point:
Where are you running this? Although the JS spec says that tail recursion is optimized, Google refused to implement that on V8, therefore it does not get optimized on node or chrome.safari implements it, that's where I test most of the code.
If this still fails on safari, I'll figure out the issue. It could also be the difference between a ternary ?: and an if statement, depending on how the tail detection is implemented.
Hi,
I was reading http://raganwald.com/2015/02/07/tail-calls-defult-arguments-recycling.html, and it's fascinating stuff, thank you.
However, I was doing some testing myself, and I found that the tail call version of
length()
still hitsMaximum call stack size exceeded
at ~ 8,400 item long arrays on my Macbook ProIs this because of the inefficiency of
[first, ...rest]
. My understanding of the article was that the recursion was now ok because JavaScript optimizes away the function call overhead and stack space.I'm just finding both the tail call
length
and the inefficient one fall over at the same point:The text was updated successfully, but these errors were encountered: