What If Python Replaced Elisp?

[Kragen Sitaker]

In article <jm1y4.121$Lh9.181468160 at newsb.telia.net>,
Fredrik Lundh <effbot at telia.com> wrote:
>Neel Krishnaswami <neelk at brick.cswv.com> wrote:
>> lst = []
>> for i in range(100):
>>     lst.append(i**2 + i**2)
>>
>> result = reduce(operator.add, lst)
>
>You're assuming that you know exactly what "range",
>"reduce", and "operator.add" evaluates to.
>
>but you don't, in today's Python.

You can compile an optimized version on the assumption that they are
what they usually are, and an unoptimized version in case they change,
and choose which to run at run-time.  Or you can invalidate the
compiled version when the change happens.

Using global analysis, you may also be able to prove that range,
reduce, operator.add, and lst.append never get changed, or don't get
changed until after the above code runs.

At the very worst, you know that if range, lst.append, operator.add,
and reduce don't change themselves or one another, then they won't
change during the execution of the above code.  So if you compile it
just before executing it, you'll be OK.

It's a problem that Lisp compilers and the SELF compiler have wrestled
with for a long time.  It's not insoluble, but it's not like writing a
FORTH compiler.
-- 
<kragen at pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)