Op 07-10-13 23:27, random...@fastmail.us schreef: > On Sat, Oct 5, 2013, at 3:39, Antoon Pardon wrote: >> What does this mean? >> >> Does it mean that a naive implementation would arbitrarily mess up >> stack traces and he wasn't interested in investigating more >> sophisticated implementations? >> >> Does it mean he just didn't like the idea a stack trace wouldn't be a >> 100% represenatation of the active call history? >> >> Does it mean he investigated more sphisticated implementations but found >> them to have serious short comings that couldn't be remedied easily? > > The entire point of tail call optimization requires not keeping the > intervening stack frames around, in _any_ form, so as to allow > arbitrarily deep recursion without ever having the possibility of a > stack overflow. An implementation which reduced but did not eliminate > the space used per call would not be worthwhile because it would not > enable the recursive functional programming patterns that mandatory tail > call optimization allows.
So? What about an implementation that would keep its stackframes normally until it deteced recursion had occured. From then on it would only keep what it already had plus the four top stackframes (assuming it are all tail calls for the moment). This would allow for a stacktrace of the last four calls and essentially doesn't need any space per call from then on. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
