Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #55411 > unrolled thread

Re: Tail recursion to while iteration in 2 easy steps

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Tail recursion to while iteration in 2 easy steps random832@fastmail.us - 2013-10-03 10:09 -0400
    Re: Tail recursion to while iteration in 2 easy steps Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-04 02:05 +0000

#55411 — Re: Tail recursion to while iteration in 2 easy steps

On Wed, Oct 2, 2013, at 17:33, Terry Reedy wrote:
> 5. Conversion of apparent recursion to iteration assumes that the 
> function really is intended to be recursive.  This assumption is the 
> basis for replacing the recursive call with assignment and an implied 
> internal goto. The programmer can determine that this semantic change is 
> correct; the compiler should not assume that. (Because of Python's late 
> name-binding semantics, recursive *intent* is better expressed in Python 
> with iterative syntax than function call syntax. )

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).

[toc] | [next] | [standalone]

#55451

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web