functional programming

Michael Hudson mwh21 at cam.ac.uk
Tue Feb 22 13:04:19 EST 2000


bjorn <bjorn at roguewave.com> writes:

> Maybe I'm dense, but what is stopping us from implementing tail call
> optimization (of which tail recursion is just a special case) with the
> cu= rrent Python implementation.  Identifying a call in a tail
> position is a simple static analysis that isn't affected by Python's
> dynamicity (is that a wor= d?).  Once they're identified you only need
> to translate a call to a jump inste= ad of a push return address and
> jump.  There is no semantic change to Python.

Ta da!

http://starship.python.net/crew/mwh/bch/module-bytecodehacks.tailr.html

Generates rather poor code and can't do mutually tail recursive
functions, but works.

It's *very* easy to spot tail calls in Python bytecode; just look for
a CALL_FUNCTION followed by a RETURN_VALUE.  It would probably be
fairly simple to add a TAIL_CALL opcode to the interpeter, and then
translate CALL_FUNCTION/RETURN_VALUE pairs to this new opcode.  I
might do it one day if I get bored.

Tail recursion can make debugging much harder, mind.

Oh, hang on: exceptions. Arse (I think).

never-mind-it-was-a-nice-idea-ly y'rs
Michael

-- 
very few people approach me in real life and insist on proving they are
drooling idiots.                         -- Erik Naggum, comp.lang.lisp



More information about the Python-list mailing list