Functional languages vs. hybrids (was Re: How does Ruby compare to Python?? How good is DESIGN ofRubycompared to Python?)
Paul Prescod
paul at prescod.net
Sat Feb 28 11:44:14 EST 2004
Joe Mason wrote:
>...
> Down in the depths of the compiler, the simplest way to
> implement (C-style) functions is just to total up all the
> parameters and local space it will need and lay out a
> stack frame.
We're talking about Python and the Python compiler generates Python
bytecodes, not machine code!
> ...hybrid languages like Python and Ruby and Java and C#, then. It's
> the combination of first-order functions *and* side effects that kills
> you. (I don't know enough Java/C# to know if they have nested functions
> and "function pointers" or equivalent - it actually wouldn't surprise me
> if Java doesn't.)
Python function calling was never even remotely close to machine
function calls for a variety of reasons (primarily the fact that we're
talking about an interpreter rather than a compiler).
You may well be right that Python _would_ pay a cost for nested
functions if its function model was not already substantially more
complicated, sophisticated and expensive than C's. But there are all
sorts of reasons that Python function calls are slow and I frankly think
that nested scopes are the least of them:
* Python functions use a stack that is different than the C stack
(that's why stackless is even possible)
* Python functions have complicated calling conventions (varargs,
optional args, keyword args)
* Python functions are called through a protocol that supports other
types of "callables"
* Python integers etc. must be unboxed after the function call to do
anything useful with them
All of these performance-sucking features were in Python long before
nested functions.
Paul Prescod
More information about the Python-list
mailing list