What If Python Replaced Elisp?

Thomas Bellman bellman at lysator.liu.se
Fri Mar 10 11:12:08 EST 2000


"Fredrik Lundh" <effbot at telia.com> writes:

> Neel Krishnaswami <neelk at brick.cswv.com> wrote:
[...]
>> You can statically infer the type of result, the final size of lst,
>> avoid actually allocating a range() object, eliminate the the
>> typechecks that make sure that i has a __pow__ method, the bounds
>> checks on the range object, do available expressions analysis on the
>> i**2 to avoid calculating it twice, and probably a few more
>> optimizations that I don't know about.

> You're assuming that you know exactly what "range",
> "reduce", and "operator.add" evaluates to.

> but you don't, in today's Python.

Sure you can.  But it requires a lot more effort.  You need to
analyze the entire program.  Good LISP compilers do this already.
However, it is rather time and space consuming to do so on large
programs.

Then, you could compile two versions of that code, one that
assumes range, reduce and operator.add behave in their normal
way, and one that doesn't, and check at runtime whether the
assumptions hold and use the right version depending on the
outcome of the check.  Existing compilers, even C compilers,
do variants of this too, so it's not science-fiction.


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
"If you ignore performance problems long enough, they   !    bellman @
 somehow seem to go away."          -- Barry A Warsaw   ! lysator.liu.se



More information about the Python-list mailing list