Jesse Welton <jwelton at pacific.mps.ohio-state.edu> wrote:

	As to whether [TRO] would be a good idea, the consensus seemed
	to be that it would interfere too much with the debugger's
	strengths.  (Tail recursion optimization effectively erases all
	record of intermediate calls, making it much harder (or
	impossible) to back-trace the execution of a running program.)
	
There's a bit of a vicious circle here.
Knowing that you have TRO available means you can adopt quite a different
style of programming.  For example, Common Lisp says nothing about TRO, and
one Common Lisp implementation I used bounded the size of each process's
stack to 64 k pointers.  You wouldn't believe how fast that got used up,
so code written for that Lisp tended to use (a precursor of) the 'loop'
macro quite heavily.  Scheme explicitly requires TRO, and one writes in
a _VERY_ different style for Scheme.  For another example, the old DEC-10
Prolog compiler didn't do TRO, so old DEC-10 Prolog code tended to use
backtracking (especially in the form of "failure-driven loops") for tasks
where recursion would have been more natural.  When the "new" compiler
for DEC-10 Prolog was written to support TRO, old code still worked, but
we suddenly realised how ugly it had always been.

A compromise is always possible.  If you use an abstract instruction set,
instead of compiling to native code, nothing stops you having two different
VMS, a fast memory-economical one and a record-keeping debugging one.
In effect,
    copy arguments into %o registers (but as if they were %i registers)
    tail_call label
    return
would, in "cheap" execution mode
    - overwrite the %i registers
    - jump
and in "debugging" execution mode
    - write into the %o registers
    - do a normal call
    - do a normal return

Such a compromise means that when something blows up, you can't see all
the stack frames that would have been there, but you _can_ wind back to
an earlier point and restart in debugging mode.  It works very well indeed
for declarative languages, not so well for imperative languages (amongst
which I count Smalltalk and Self, because objects are mutable).

I note that Sun's SPARCompiler C compiler does TRO, and I can't honestly
say I've ever regretted that.  It has a lot to do with HOW you debug, and
SUnit is such a wonderful aid to bug-hunting that maybe the debugger could
lose a bit of power without overall harm.