Re: Question from a newbie

> Also note that your intuition is incompatible with a
> language like Scheme, which requires that recursive tail
> calls not consume stack space, so that you can express loops
> in terms of recursion.  There is no place to save dead
> locals during a tail call.  Even for other languages, it may
> have a significant optimization impact.

Scheme is not a problem since tailcalls are "part of the
language contract" between implementors and users.  Also,
note that there is no further loss of debugging information
compared to debugging loops in other languages -- in a while
loop there is no history of previous values of the loop
controlling variable.

Almost no other language promises tailcall elimination and in
such cases I'd like the ability to look at locals at least
when a debug option is given the compiler (the fact my
expectation is frequently not satisfied _is_ because
debuggability is sacrificed to optimization and hence my
`lowered expectation' comment).

As for any optimization impact, I don't have an answer;
merely an observation that agressive optimizations use
assumptions that _break_ the so-called `contract' as soon as
you bring in debugging.  One requires a fairly detailed
knowledge of optimization tricks used to debug a highly
optimized compiled code and if things break with the next
version of the compiler one has to learn many of the same
tricks all over again.

Kind of ironic that people are still optimizing for
performance and not debuggability even when we have
progressed from 100Mhz to 2+Ghz processors in less than 10
years and when systems are increasingly more complex and
harder to debug.  Also kind of ironic that people explicitly
turn off debugging when shipping code but I guess that is a
different discussion and outside the charter of gclist.

-- bakul