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.
