Tail recursion to while iteration in 2 easy steps

[Steven D'Aprano]

On Thu, 03 Oct 2013 10:09:25 -0400, random832 wrote:

> Speaking of assumptions, I would almost say that we should make the
> assumption that operators (other than the __i family, and
> setitem/setattr/etc) are not intended to have visible side effects. This
> would open a _huge_ field of potential optimizations - including that
> this would no longer be a semantic change (since relying on one of the
> operators being allowed to change the binding of fact would no longer be
> guaranteed).

I like the idea of such optimizations, but I'm afraid that your last 
sentence seems a bit screwy to me. You seem to be saying, if we make this 
major semantic change to Python, we can then retroactively declare that 
it's not a semantic change at all, since under the new rules, it's no 
different from the new rules.

Anyway... I think that it's something worth investigating, but it's not 
as straight forward as you might hope. There almost certainly is code out 
in the world that uses operator overloading for DSLs. For instance, I've 
played around something vaguely like this DSL:

chain = Node('spam') 
chain >> 'eggs'
chain >> 'ham'
chain.head <= 'cheese'

where I read >> as appending and <= as inserting. I was never quite happy 
with the syntax, so my experiments never went anywhere, but I expect that 
some people, somewhere, have. This is a legitimate way to use Python, and 
changing the semantics to prohibit it would be a Bad Thing.

However, I can imagine something like a __future__ directive that 
enables, or disables, such optimizations on a per-module basis. In Python 
3, it would have to be disabled by default. Python 4000 could make the 
optimizations enabled by default and use the __future__ machinery to 
disable it.


-- 
Steven