4 ms·

the reason TCO is not implemented in V8, iirc, is because of developer experience and needing devtools to faithfully dump the call stack that hasnt been flatten

the reason TCO is not implemented in V8, iirc, is because of developer experience and needing devtools to faithfully dump the call stack that hasnt been flattened, because that's what's expected of js DX. does JSC's implementation solve this? do they exhaust the stack only when devtools are open, or smth? maybe they just keep the last 10 frames in memory for devtools? (that would make most sense to me)

pjmlp 3y ago
This is a solved problem on programming languages where it is part of the specification, like Scheme. Basically the debugging info and what actually happens isn't 1:1, rather the logical model of the execution.
- twic 3y ago
  What is the solution?
  - pjmlp 3y ago
    The debugger has metadata that allows faking the execution flow as if the frames haven't been erased, and how deep it happens to be, naturally only when active.
anonymoushn 3y ago
This is a silly justification I think, in the sense that V8 could implement this in a way that can provide stack traces for all stacks that are short enough for a human to browse while also executing programs that use tail calls as goto correctly.
hajile 3y ago
Nobody cares that loops don’t have stack frames. Few people cared for decades that async functions lost stack traces. It’s just a bad excuse.
- leeoniya 3y ago
  touché
deredede 3y ago
See [1] (Filip's commit message introducing ShadowChicken is also quite well written if a bit more technical [2]). [1] https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-in-webkit/ https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... [2] https://bugs.webkit.org/attachment.cgi?id=274533&action=review https://bugs.webkit.org/attachment.cgi?id=274533&action=revi...