Software bugs aren't inevitable

[Aahz]

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.