<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 19 February 2016 at 03:13, Gary Guo <span dir="ltr">&lt;<a href="mailto:nbdd0121@hotmail.com" target="_blank">nbdd0121@hotmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div><div dir="ltr"><span class=""><div>Andreas &lt;<a href="mailto:rossberg@google.com" target="_blank">rossberg@google.com</a>&gt; wrote:</div><div>&gt; This would be fairly difficult to support by implementations. In V8, for example, we currently have no way of reconstructing that information, nor would it be easy or cheap to add that. A frame is created by the callee, but that does not know how it got called. Funnelling through that information would effectively require a hidden extra argument to _every_ call.</div><div><br></div></span><div>Placing a boolean flag theoretically should not introduce too much overhead.</div></div></div></blockquote><div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><div>Practically, though, as I said, it would require passing an extra argument with every call, even if its information content is just a bit (or equivalently, having two entry points to every function, which would be &quot;fun&quot;). It also requires storing this bit in every stack frame, which, for V8 at least, would require allocating an additional word in every stack frame, because there is no other space left for it. So, it would likely be _substantial_ overhead in calling conventions, in both time and space.</div><div></div></div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr"><div> If we are not going to indicate tail call some way, debugging might be extremely difficult, and the stack result might be making no sense at all.</div></div></div></blockquote><div><br></div><div>A tail call is a jump. Just like other jumps, you shouldn&#39;t expect their history to be visible in the continuation (which is what a stack trace represents). I agree that JS programmers might be surprised, and will have to relearn what they know. But wrt to debugging the situation is the same as for loops: you can&#39;t inspect their history either. (And functional programmers in fact see loops as just an ugly way to express self tail recursion. :) )</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I&#39;d argue that the real problem is that ES6 repurposed existing return syntax for tail calls. This would probably be much less of an issue if tail calls were a syntactically explicit feature. I wonder if we can still fix that...</div><div class="gmail_extra"><br></div><div class="gmail_extra">/Andreas</div><div class="gmail_extra"><br></div></div>