Yoann Padioleau wrote:
> i dont see TCO as part of the design of scheme, but more to the design
> of the compiler.
> I prefer than a langage designer focus on programmer productivity rather
> than program efficiency (that is why i hate all those C/C++/... langages).
The mistake that C/C++ makes is that they strike the wrong balance between
programmer productivity and program efficiency. That's a big issue that
Scheme addresses very successfully.
Programmer productivity and program efficiency can't always be completely
separated, and certainly not in the case of tail-call optimization. Without
TCO, a recursive programming style would often not be practical. Without a
recursive programming style, much functional programming would not be
possible. So tail-call optimization is an important feature for programmer
As I said in another reply just posted, the point is to enable programmer
productivity, by ensuring that a programmer can rely on high-level
abstractions without paying an undue performance penalty.
This is one reason why it is possible to write systems like, say, the
symbolic mathematics program JACAL
(http://www.swiss.ai.mit.edu/~jaffer/JACAL.html) in Scheme. Even if someone
was perverse enough to write such a system in Perl, the performance would be
likely to be unacceptable. (Although, with a water-cooled hyperthreaded
3GHz Intel Xeon, who knows?)