In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (Aahz) writes: >> In article <[EMAIL PROTECTED]>, >> Paul Rubin <http://[EMAIL PROTECTED]> wrote: >>> >>>Every serious FP language implementation optimizes tail calls and thus >>>using recursion instead of iteration doesn't cost any stack space and >>>it probably generates the exact same machine code. >> >> While that's true, one of the reasons Guido has historically rejected >> this optimization is because there are plenty of recursive algorithms >> not amenable to tail-call optimization. > >That seems amazingly silly. Sort of like refusing to hoist function >definitions because not all function definitions can be hoisted. Or >choose your favorite "sometimes-I-can-sometimes-I-can't" optimization. > >Since the BDFL is *not* known for doing even mildly silly things when >it comes to Python's design and implementation, I suspect there's more >to the story than that.
Note that I said "one reason". The primary reason is that tail-call optimization destroys the call stack, which means that exception semantics would have to change. If tail-call optimization were more useful, he might be willing to consider the tradeoff, but since it isn't... -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. -- http://mail.python.org/mailman/listinfo/python-list
