Well, if the stack still shows the function call, it isn't a bad idea.
On Wed, Jul 9, 2014 at 2:17 AM, Armin Rigo <ar...@tunes.org> wrote: > Hi John, > > On 8 July 2014 22:57, John Smith <4u5vj...@gmail.com> wrote: > > Yes. But tail-call optimization is a performance optimization, so it goes > > well with PyPy. I wanted to suggest to Travis that he not be discouraged > > from his idea and give him another idea for getting tail-call more widely > > used compared to making his own fork of PyPy. > > Yes, that sounds like an idea --- which I wouldn't call a *good* idea > because I still think that tail call optimization is a bad idea in > Python, but that's a personal issue. If you want to implement such a > pure Python compiler modification, you can; but it's a bit unclear > what kind of alternate Python code or bytecode to emit. We could > consider adding an experimental bytecode to the standard PyPy, even if > it is normally never used, as long as it's extensively tested. > Designing the bytecode correctly is an open question. > > > A bientôt, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
