In article <863bo5j0br.fsf at bhuda.mired.org>, Mike Meyer <mwm at mired.org> wrote: >aahz at pythoncraft.com (Aahz) writes: >> In article <7xpsrb78tn.fsf at ruckus.brouhaha.com>, >> Paul Rubin <http://phr.cx@NOSPAM.invalid> 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 (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4