The whole idea with tail call elimination is that a stack trace shouldn't be able to see the frames for the tail calls, because the tail call reuses the frame. To add support for tracking the tail call stack frames, you would need to modify the compiler to output code that specifically keeps track of "elided tail call frames", and you would need to update the stack trace traversal code to be able to recognize the extra debug information.
Sure, it's something you could build into a new toolchain, but adding something like this to the JVM would be harder due to the constraints already placed on the JVM. Furthermore I don't know of such support in any toolchains, not even for Lua or Scheme, both of which guarantee tail call optimization. (If anybody has an example, please share!)
Lua's stack trace includes an indication that 1 or more tail calls happened, but not how many
$ cat tailrec.lua
function f(g,n)
if n == 0 then
error("oh no")
end
return g(g,n-1)
end
f(f,5)
$ lua tailrec.lua
lua: tailrec.lua:3: oh no
stack traceback:
[C]: in function 'error'
tailrec.lua:3: in function 'f'
(...tail calls...)
tailrec.lua:7: in main chunk
[C]: in ?
> There are some non-standard ECMAScript features in JavaScript that work differently in the presence of PTC.
Java has a strict spec, and the relevant methods which would break aren’t non-standard like they are in JavaScript.
If you’re willing to change the spec (I think Loom does) then yeah, but you can’t implement it as an ‘optimisation’ until then, because it’s not an optimisation if it changes behaviour.
