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