Error stack strawman

[Andreas Rossberg]

On 19 February 2016 at 03:13, Gary Guo <nbdd0121 at hotmail.com> wrote:

> Andreas <rossberg at google.com> wrote:
> > 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.
>
> Placing a boolean flag theoretically should not introduce too much
> overhead.
>

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
"fun"). 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.



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

A tail call is a jump. Just like other jumps, you shouldn'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't inspect their history either. (And functional
programmers in fact see loops as just an ugly way to express self tail
recursion. :) )

I'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...

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160219/7312c6fd/attachment.html>