Saturday, August 31, 2013

Stack traces vs. TCO: Do non-tail recursive languages generally have efficient stack frames?

Stack traces vs. TCO: Do non-tail recursive languages generally have
efficient stack frames?

One reason I have heard for some languages to not support tail-call
optimization (TCO) is that this optimization comes at the cost of
obfuscating the call stack if/when debugging should require one to look at
a stack trace. (I have heard other reasons such as "The virtual machine
does not support it", but let's disregard Java for now.)
It seems then that for some set of languages where TCO would be possible,
but one does not perform it, the only purpose of stack frames is to
maintain meta-data for any eventual stack trace to be generated. I.e., the
stack frame could be minimal, containing only enough information to
generate the stack trace.
Question(s): Would it not make sense to minimize the size of such stack
frames? Would it not minimize the use of stack space, thus allowing deeper
levels of recursion before running out of space? Is this attempted in
languages where this thought applies? (I'm thinking in particular of
Python.) Or is this a lost effort with regards to actual space saved? (I
imagine that the meta-data necessary for generating nice stack traces is
actually quite a lot compared to what's normally in a stack frame.)
Idea in short: Minimize size of stack frames as an alternative to TCO.
PS. My thoughts are not based on any actual benchmarks. I could be way off
here.

No comments:

Post a Comment