Possibly Pythonic Tail Call Optimization (TCO/TRE)
Rustom Mody
rustompmody at gmail.com
Fri Jul 17 00:28:55 EDT 2015
On Wednesday, July 15, 2015 at 4:54:51 PM UTC+5:30, Marko Rauhamaa wrote:
> Ned Batchelder:
>
> > On Wednesday, July 15, 2015 at 6:56:10 AM UTC-4, Marko Rauhamaa wrote:
> >> Ned Batchelder :
> >> > I don't understand this, can you explain more? Are you saying that the
> >> > Python specification shouldn't specify what x becomes?:
> >> >
> >> > def who_knows():
> >> > pass
> >> >
> >> > x = who_knows()
> >>
> >> Yes, that's what I'm saying. The implementation would be free to assign
> >> any value whatsoever to x.
> >
> > I don't understand why that is helpful for TCE? Can you explain? How does
> > specifying None make "smooth TCE" difficult?
>
> As Chris already pointed out, tail procedure calls can't be eliminated
> otherwise. An example:
>
> def some_func():
> do_stuff()
> more_stuff()
>
> Now, for Python to replace the call to "more_stuff()" with a simple
> jump, there can't be an implicit "return None" following it. Instead,
> "some_func()" must be allowed to return whatever "more_stuff()" returns.
>
> You could require the programmer to write:
>
> def some_func():
> do_stuff()
> return more_stuff()
>
> but that's not good style. In fact, it is not good style to write code
> that omits "return None" when None needs to be returned. IOW, the
> unspecifiedness of procedure return values is already the unwritten
> assumption in good Python code.
An interesting insight.
For sometime now I am seeing that C's void-return's are a mess-up of Pascal procedures.
And python's None-returns are a mess-up of C's void-return:
http://blog.languager.org/2015/06/functional-programming-moving-target.html
This was mostly from pedagogic data of observing student confusions
Now you are giving a new take on why None-return could be a language-design
anti-pattern. So thanks for that.
More information about the Python-list
mailing list