Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tail call length still hits call stack #99

Open
adamdawkins opened this issue Jul 18, 2018 · 1 comment
Open

tail call length still hits call stack #99

adamdawkins opened this issue Jul 18, 2018 · 1 comment

Comments

@adamdawkins
Copy link

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 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:

const length = ([first, ...rest], numberToBeAdded = 0) =>
  first === undefined
    ? numberToBeAdded
    : length(rest, 1 + numberToBeAdded)
@raganwald
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants