Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Rustom Mody]

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.