1. With tail-call optimisation, don't some stack frames just completely disappear, so by default there's no way for an interpreter to list them in a backtrace? I might have completely misunderstood TCO, of course. And if we redefined 'def so that it inserts code to build a stack trace, would this not cause the kind of memory leak that TCO is designed to eliminate, unless the stack-trace builder detects and excludes recursive calls?
2. Backtraces are even nicer with source file and line number information. Maybe I'm spoilt, having grown up in javaland. But with macro-expansion and quasiquotation and so on, how can an interpreter tell what file/line number a particular expression comes from? And as a user (an arc user, that is) trying to make sense of a back trace (obviously not a real hacker, as noted by almkglor above), is it more useful to know the source of the macro into which my erroneous expression expanded, or to know the pre-expansion source of the problem?
I haven't a clue what other lisps do for backtraces.
1. Yes. This is actually good. You don't want a 1000-iteration loop cluttering a backtrace do you?
Without TCO:
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
....985 more times....
in function foo
in function bar
from top level
With TCO:
in function gs42
in function foo
in function bar
from top level
Less is more?
That said, if you're implementing a state machine using tail-called functions, you lose the trace of the state and can only get the current state (arguably a good thing too - you don't want to have to hack through 600 state transitions, either). You'll probably have to dump the state on-screen or on-disk somehow instead.
2. Yes, this is difficult. IIRC some Schemes actually internally use an abstract syntax tree (not lists) and make macros work on that tree, not on lists. The abstract syntax tree includes the file and line number information.
The problem here is: what do you end up debugging, the macro or the code that uses the macro? If the macro-expansion is a complicated expression, then the bug might actually be in the macro, with the original code quite correct.
In arc2c the file and line number info are lost pretty early. Maybe we could use an AST direct from the file read-in, and silently fool macros into thinking that the AST is a list.
1. I've thought about this too and then looked how it worked in SBCL, and I've seen that it doesn't show tail optimized functions in the stack backtrace. I've developed a few programs with SBCL and this has never been a problem.
