What If Python Replaced Elisp?

0 views
Skip to first unread message

taa...@sandia.gov

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to
(If you're tempted to post a followup saying something like "Doing
this would be a waste of time and effort", don't. Just accept that
you've missed the point of this posting and move on.)

This morning I was making some changes to my .emacs file and I thought
how much easier it would be to use Python instead of Elisp for this
purpose. And that got me to thinking about how appropriate Python
would be in this role.

I'm just beginning to program in Python (I've finished "Learning
Python" and am currently devouring "Python & Tkinter Programming").
And I'm a far cry from an Elisp expert (I know just enough to maintain
my .emacs file).

Now I realize that rewriting XEmacs (my favorite emacsen) to use
Python rather than Elisp would be an enormous undertaking that would
(probably?) not payoff. But I believe that the mental exercise involved
in thinking about what this would entail would be a good learning
experience about Python's strengths and weaknesses.

So I'll start us off:

Elisp function definitions may be interactive or non-interactive. If
interactive, then you can use a string to specify how the parameters
are obtained from the user (types, prompts, etc.). How would this be
done in Python? (Beginner opinion: I would make all functions
interactive and use a combination of default arguments and explicit
parameter checks. For example, default an argument to None and check
for this at the beginning of the function, if the argument is None,
then prompt the user for input. Is there a better way?)

I saw a comparison of Lisp and Python at
<http://www.norvig.com/python-lisp.html> which stated that Lisp can be
about 100 times faster than Python. I'm going to assume that this
doesn't hold true for Elisp. But is Python fast enough to be a
scripting engine for an editor? (Beginner WAG: Python 'feels' just as
fast, if not faster, than Elisp. But some of the packages
(e.g. font-lock) rely heavily on regular expression parsing, which may
be slower in Python.)

Would it be easier to add a COM (automation) interface to XEmacs if
Python were used instead of Elisp?

Would the GUI be improved by using Tkinter or wxWindows?

What other advangages/disadvantages would arise due to this change?

BTW, are there any extensible editors out there that use Python as
their scripting language?

Thanks,
Tad

Warren Postma

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to
Why rewrite EMACS? Why not start from scratch with Python and see what
develops?

I never learned EMACS because I hated LISP. I took a LISP course in 2nd year
CompSci. Blech!

I would love an Editor written in Python, scriptable in Python. IDLE is
great except for when I need to use a command line machine. In fact, I find
a text screen less distracting when I'm writing reams of code. I think a
Python+Curses based editor would be great. Does such a beastie exist?

Warren

Gregoire Welraeds

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to Warren Postma
In reply to the message of Warren Postma sent on Mar 8 (see below) :

> I would love an Editor written in Python, scriptable in Python.

scriptabe in Python... I think this is the case with VIM5.6 compiled with
the Python interpreter module.

BTW: I love VIm :)

--
Life is not fair
But the root password helps
--

Gregoire Welraeds
gr...@perceval.be
Perceval Development team
-------------------------------------------------------------------------------
Perceval Technologies sa/nv Tel: +32-2-6409194
Rue Tenbosch, 9 Fax: +32-2-6403154
B-1000 Brussels general information: in...@perceval.net
BELGIUM technical information: help...@perceval.net
URL: http://www.perceval.be/
-------------------------------------------------------------------------------

On Wed, 8 Mar 2000, Warren Postma wrote:

> Date: Wed, 8 Mar 2000 10:47:32 -0500
> From: Warren Postma <em...@geocities.com>
> To: pytho...@python.org
> Newsgroups: comp.lang.python
> Subject: Re: What If Python Replaced Elisp?

> --
> http://www.python.org/mailman/listinfo/python-list
>
>

William Annis

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to

Gregoire Welraeds <gr...@perceval.be> writes:

> > I would love an Editor written in Python, scriptable in Python.
>
> scriptabe in Python... I think this is the case with VIM5.6 compiled with
> the Python interpreter module.

One can use CoolEdit, which has a funky widget set, but can
have Python linked in.

Also, you can use Python to talk to wily windows, although
wily is wildly minimalist, especially compared to Emacs.

http://www.netins.net/showcase/Comput-IT/cooledit/index.html
http://www.cs.su.oz.au/~gary/wily/

--
William Annis - Emacs Lover and Fanatic - Biomedical Computing Group
an...@biostat.wisc.edu PGP ID:1024/FBF64031
Mi parolas Esperanton - La Internacian Lingvon www.esperanto.org

Fredrik Lundh

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to
taa...@sandia.gov wrote:
> This morning I was making some changes to my .emacs file and I thought
> how much easier it would be to use Python instead of Elisp for this
> purpose. And that got me to thinking about how appropriate Python
> would be in this role.

before you continue down this road, be sure you
read the many threads over in emacs land in which
people have proposed similar things. lots of flames,
but also lots of intelligent arguments for why this
isn't necessarily a great idea. no need to repeat
them all on this newsgroup.

(to find them, search for "Perl" on comp.emacs
and comp.emacs.xemacs).

> But is Python fast enough to be a scripting engine
> for an editor?

heck, if you know what you're doing, you can implement
the entire editor in Python, on top of a raw graphics API.
been there, done that ;-)

> BTW, are there any extensible editors out there that use Python as
> their scripting language?

sure. lots of them. IDLE, PythonWin, vim, and a number of
others

maybe it would be easier to start in the other end?

(that is, make one of them good enough to replace emacs -- for
your own personal use, at least. making someone that allows
*everyone* to replace emacs would be a gargantuan effort).

</F>

Grant Edwards

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to
> Also, you can use Python to talk to wily windows, although
>wily is wildly minimalist, especially compared to Emacs.

Compared to Emacs, what isn't?

;)

--
Grant Edwards grante Yow! I'LL get it!! It's
at probably a FEW of my
visi.com ITALIAN GIRL-FRIENDS!!

Matt Curtin

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to
>>>>> "Tad" == taashlo <taa...@sandia.gov> writes:

Tad> This morning I was making some changes to my .emacs file and I
Tad> thought how much easier it would be to use Python instead of
Tad> Elisp for this purpose.

Would it be easier for you because you're more comfortable with Python
than with XEmacs Lisp?

Tad> Now I realize that rewriting XEmacs (my favorite emacsen) to
Tad> use Python rather than Elisp would be an enormous undertaking
Tad> that would (probably?) not payoff.

Emacs folks, I believe especially XEmacs folks, have discussed this
several times. The most common idea of this type seems to be
replacing the XEmacs Lisp engine with Perl, or adding Perl as a second
engine for extension. The less radical discussions of this type have
been moving from ELisp to GUILE (for GNU Emacs) and whether to move to
GUILE or Common Lisp as the extension language for XEmacs.

Look for "Perl", "Common Lisp", and "GUILE" in news:comp.emacs.xemacs
archives and in xemacs mailing lists, which are archived at
http://www.xemacs.org/. That should provide some useful and
interesting food for thought on the topic.

Tad> I saw a comparison of Lisp and Python at
Tad> <http://www.norvig.com/python-lisp.html> which stated that Lisp
Tad> can be about 100 times faster than Python. I'm going to assume
Tad> that this doesn't hold true for Elisp.

Obviously, how much of a difference there will be will depend largely
on the specific task at hand. However, I think it's probably safe to
say that byte-compiled XEmacs Lisp is much faster than Python on
average. It would be interesting to do some tests to see just what
kind of difference there is.

Tad> (Beginner WAG: Python 'feels' just as fast, if not faster, than
Tad> Elisp. But some of the packages (e.g. font-lock) rely heavily
Tad> on regular expression parsing, which may be slower in Python.)

Keep in mind that your comparisons here aren't even close to being
apples-to-apples. It would be more interesting to see you do
something like rewrite `hanoi' in Python and compare that speed to
what's in XEmacs. Until you're working with the same program, one
implemented in XEmacs Lisp and the other in Python, you're not going
to have a good feel for which is really faster.

Tad> Would it be easier to add a COM (automation) interface to
Tad> XEmacs if Python were used instead of Elisp?

I do not see why.

Tad> Would the GUI be improved by using Tkinter or wxWindows?

Improved? I doubt it. As an example of the GUI's completeness,
XEmacs has hooks for things like CDE drag-n-drop.

Tad> What other advangages/disadvantages would arise due to this
Tad> change?

A huge amount of code would need to be implemented in the language of
any new engine. A lot of things would need to change the way that
they implement various pieces, but most of these would be manageable.
implemented in a way that's depending on a "functional" viewpoint.

I definitely wouldn't like any such change. I don't see any real
advantages that would be offered by using Perl, Python, or anything
else so radically different from XEmacs Lisp. My question is "what
does XEmacs Lisp not do for you?" If it's a question of not knowing
the tool (as it has been in the case of some similar suggestions in
the past), the correct answer is probably to learn the tool better
instead of suggesting a replacement.

--
Matt Curtin cmcu...@interhack.net http://www.interhack.net/people/cmcurtin/

Harald Hanche-Olsen

unread,
Mar 8, 2000, 3:00:00 AM3/8/00
to
+ grant@nowhere. (Grant Edwards):

| >[...] wildly minimalist, especially compared to Emacs.


|
| Compared to Emacs, what isn't?

Windows? Or any other product from the same company?

Or, closer to home for most emacs users, what about X11?

--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- "There arises from a bad and unapt formation of words
a wonderful obstruction to the mind." - Francis Bacon

Jon K Hellan

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to
Matt Curtin <cmcu...@interhack.net> writes:

> Obviously, how much of a difference there will be will depend largely
> on the specific task at hand. However, I think it's probably safe to
> say that byte-compiled XEmacs Lisp is much faster than Python on
> average. It would be interesting to do some tests to see just what
> kind of difference there is.

This example is from ch. 14 of the Emacs Lisp Reference manual:

(defun silly-loop (n)
"Return time before and after N iterations of a loop."
(let ((t1 (current-time-string)))
(while (> (setq n (1- n))
0))
(list t1 (current-time-string))))

(Automatically byte compiled) Python: 280 000 iterations/s
Byte compiled Emacs Lisp: 520 000 it/s
Byte compiled Xemacs Lisp: 820 000 it/s
Compiled Allegro Common Lisp: 110 000 000 it/s
C (-O2 and up): 110 000 000 it/s

Setup: AMD K6 233 MHz, 64 MB RAM.

Hope this helps:

Jon Kåre

Cameron Laird

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to
In article <xlxg0u0...@gold.cis.ohio-state.edu>,
Matt Curtin <cmcu...@interhack.net> wrote:
.
.

.
> Tad> Would it be easier to add a COM (automation) interface to
> Tad> XEmacs if Python were used instead of Elisp?
>
>I do not see why.
.
.
.
Because Mark Hammond has already worked miracles
in educating Python about COM.

Your general principle that elisp is already
quite refined, and more capable and mature than
naive observers realize, is unarguable.
--

Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html

Fredrik Lundh

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to
Jon K Hellan <hel...@acm.org> wrote:
> This example is from ch. 14 of the Emacs Lisp Reference manual:
>
> (defun silly-loop (n)
> "Return time before and after N iterations of a loop."
> (let ((t1 (current-time-string)))
> (while (> (setq n (1- n))
> 0))
> (list t1 (current-time-string))))
>
> (Automatically byte compiled) Python: 280 000 iterations/s

interesting. I get:

File "bzzt.py", line 1
(defun silly-loop (n)
^
SyntaxError: invalid syntax

> Byte compiled Emacs Lisp: 520 000 it/s
> Byte compiled Xemacs Lisp: 820 000 it/s
> Compiled Allegro Common Lisp: 110 000 000 it/s
> C (-O2 and up): 110 000 000 it/s

</F>

chof...@dvcorp.com

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to

> I definitely wouldn't like any such change. I don't see any real
> advantages that would be offered by using Perl, Python, or anything
> else so radically different from XEmacs Lisp. My question is "what
> does XEmacs Lisp not do for you?" If it's a question of not knowing
> the tool (as it has been in the case of some similar suggestions in
> the past), the correct answer is probably to learn the tool better
> instead of suggesting a replacement.

The big advantage I see runs something like this: look at all the great
elisp tools available even though a tiny fraction of emacs users can
write a line of elisp. Imagine what we'd have to choose from if all
those Perl, Python, Tcl, or VB programmers were hacking emacs macros!

Now I agree that rewriting emacs doesn't make a lot of sense. It would
take years just to reach the level of functionality that standard
elisp-emacs already has built in, and most of the packages I already use
would probably never get rewritten. But, boy, would I love it if there
were a COM API (or the equivalent) that would let me write macros in
Python, or tap into the vast pool of Perl hackers.

Chris

Sent via Deja.com http://www.deja.com/
Before you buy.

Samuel A. Falvo II

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to

>I saw a comparison of Lisp and Python at

><http://www.norvig.com/python-lisp.html> which stated that Lisp can be
>about 100 times faster than Python. I'm going to assume that this

I think this has a lot to do with the "explicit syntax tree" that you build
with LISP programs. Think about it -- the structure of LISP programs
directly mirrors an equivalent semantic tree built with a traditional
compiler, like C. As a result, the same types of optimizations that are
possible with languages like C are possible with the likes of LISP too.
Many LISP environments compile to raw assembly language too, though I
somehow doubt elisp does this.

There is little, if anything, preventing this type of optimizability in
Python as well -- I recall a discussion from a friend of mine (Billy
Tanksley) from before I regularly read this newsgroup, indicating a desire
to switch from plain bytecodes to three-operand RISC-like, platform
independent, fixed-width codes. If memory serves me correctly, it had
something to do with run-time code optimization and efficiency.

>doesn't hold true for Elisp. But is Python fast enough to be a
>scripting engine for an editor? (Beginner WAG: Python 'feels' just as

Plenty fast enough in my opinion.

>Would it be easier to add a COM (automation) interface to XEmacs if


>Python were used instead of Elisp?

If you're going to go this route, then please also consider adding CORBA
interfaces. Having an editor that is simultaneously scriptable via COM and
CORBA will be very, very useful.

If not COM, then definately CORBA -- ORBs such as OmniORBpy and Fnorb (<--
VERY easy to use, BTW -- highly recommended) are available, and are
reasonably cross-platform, as CORBA is designed to be as independent from
its supporting environment as possible.

>Would the GUI be improved by using Tkinter or wxWindows?

I would like to see GTK myself. Tkinter just "feels" wrong to me for some
reason.

>What other advangages/disadvantages would arise due to this change?

Quite likely we'd have a kick-butt editor that didn't take up 20MB+ of drive
space. :)

--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA

Fredrik Lundh

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to
Samuel A. Falvo II wrote:
> I think this has a lot to do with the "explicit syntax tree" that you
build
> with LISP programs. Think about it -- the structure of LISP programs
> directly mirrors an equivalent semantic tree built with a traditional
> compiler, like C. As a result, the same types of optimizations that are
> possible with languages like C are possible with the likes of LISP too.

umm. does using an explicit syntax tree turn Lisp
into a statically typed language?

> There is little, if anything, preventing this type of optimizability in
> Python as well -- I recall a discussion from a friend of mine (Billy
> Tanksley) from before I regularly read this newsgroup, indicating a desire
> to switch from plain bytecodes to three-operand RISC-like, platform
> independent, fixed-width codes.

Python's interpreter spends very little time decoding
the byte codes. it spends lots of time looking things
up in dictionaries, filling in call frames, creating bound
method objects, and preparing argument tuples, just
to name a few things...

</F>

Samuel A. Falvo II

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to
In article <MFVx4.169$Mn5.17...@newsa.telia.net>, Fredrik Lundh wrote:
>umm. does using an explicit syntax tree turn Lisp
>into a statically typed language?

No, but I don't see what this has to do with the point I was trying to make
either.

>Python's interpreter spends very little time decoding
>the byte codes. it spends lots of time looking things
>up in dictionaries, filling in call frames, creating bound
>method objects, and preparing argument tuples, just
>to name a few things...

All of which can be eliminated with various optimization options. I have
yet to use Python to anything even remotely close to its fullest
capabilities, and I've been working with the language since 1.3. In fact,
I use most of Python's "unique features" for temporarily patching bugs in
code I'm interactively debugging. Finished code, however, rarely uses
anything more esoteric than nested function definitions.

I would love to be able to put something like this at the top of my Python
code:

#!/usr/bin/python -O2

... normal Python code here ...

Or, for that matter, to make such things integral to the language itself, we
could provide a pragma directive:

#
# Set various language options for remainder of code...
#

pragma {"TailRecursion": 1, "TypeInferencing": 1, ...etc... }

Fredrik Lundh

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to
Samuel A. Falvo II wrote:
> >umm. does using an explicit syntax tree turn Lisp
> >into a statically typed language?
>
> No, but I don't see what this has to do with the point I was trying to
make
> either.

then I don't understand your point -- to compile
things efficiently, you need to know what types
your variables have.

in Python, you don't know that, no matter what
tree structure or byte code format you use.

> >Python's interpreter spends very little time decoding
> >the byte codes. it spends lots of time looking things
> >up in dictionaries, filling in call frames, creating bound
> >method objects, and preparing argument tuples, just
> >to name a few things...
>
> All of which can be eliminated with various optimization options.

really? please explain.

</F>

Tim Peters

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to taa...@sandia.gov, pytho...@python.org
[posted & mailed]

[taa...@sandia.gov]


> (If you're tempted to post a followup saying something like "Doing
> this would be a waste of time and effort", don't. Just accept that

> you've missed the point of this posting and move on.)

Believe it or not, I actually read that paragraph <wink>.

> ...


> But is Python fast enough to be a scripting engine for an editor?

> (Beginner WAG: Python 'feels' just as fast, if not faster, than

> Elisp. But some of the packages (e.g. font-lock) rely heavily on


> regular expression parsing, which may be slower in Python.)

Regexps are done by library pkgs coded in C -- in the end, all regexp pkgs
will be exactly the same speed <0.5 wink>.

I wrote the first "heavy" Emacs Python mode (its descendant is still the
real deal), and last year redid the parsing parts of that in Python for IDLE
(Guido's 100% Python-on-Tk Python IDE). This was a challenge! "This"
meaning both of them <wink>.

The IDLE code was much easier to write, despite that my only access to the
editing buffer was thru a straw sucking it reluctantly out of Tk's text
widget as a sequence of more-or-less giant strings. Didn't matter -- it was
easy to hide most of the pain in Python.

However, speed was a real problem, and it took much more "cleverness" to
give the illusion of instantaneous response under IDLE. But raw elisp isn't
fast enough for this task either! That's why elisp exposes a bunch of
table-driven parsing functions coded in C. I didn't have that option with
IDLE.

Major language modes are substantial pieces of subtle work, so I think this
is a good point of comparison. elisp worked fine for the task, and in
several respects has special support for it. Python also worked fine, with
no special support for it. Both languages required some tricks to get
acceptable speed in extreme cases, although the most valuable of those
tricks have worked their way into elisp's out-of-the-box repertoire over the
years.

python-is-fast-enough-for-anything-it-isn't-too-slow-for-ly y'rs - tim


Tim Peters

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to pytho...@python.org
[Neel Krishnaswami]
> There are actually a whole lot of optimizations that could be done,
> but aren't, in the current Python interpreter.
>
> For example, in the following code:
>
> import operator
>
> lst = []
> for i in range(100):
> lst.append(i**2 + i**2)
>
> result = reduce(operator.add, lst)
>
> 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.

Actually not, you can't do any of that now! You currently have no way to
know that, e.g., some *other* module didn't import this one (let's call this
one "neel"), and redirect neel.range and neel.reduce to some arbitrary
functions of its own devious choosing. Heck, the call to neel.range may
even reach back in and change neel.lst to anything at all before the loop
body is entered. "i" may end up referring to an object whose __pow__ method
sends email to Afghanistan; etc.

This is why the Types-SIG is so keen to impose restrictions on what modules
can do to each others' namespaces (in the presence of optional static
typing).

> ...
> You don't have to win every game to make it to the championships. :)

you-don't-even-need-to-win-one-but-it-sure-can't-hurt<wink>-ly y'rs - tim


Johann Hibschman

unread,
Mar 9, 2000, 3:00:00 AM3/9/00
to
Tim Peters writes:

> [Neel Krishnaswami]


>> 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.

> Actually not, you can't do any of that now! You currently have no way to
> know that, e.g., some *other* module didn't import this one (let's call this
> one "neel"), and redirect neel.range and neel.reduce to some arbitrary
> functions of its own devious choosing. Heck, the call to neel.range may
> even reach back in and change neel.lst to anything at all before the loop
> body is entered. "i" may end up referring to an object whose __pow__ method
> sends email to Afghanistan; etc.

Well, surely you can generate some checks to make sure those objects
are bound to the builtin methods and then exectute the optimized code
if they are, while resorting to the "regular" version if someone has
done something strange, right? It would bloat the byte-code files a
bit, though.

I mean, this isn't anything the Scheme compiler-writers haven't
already had to do.


--
Johann Hibschman joh...@physics.berkeley.edu

Neel Krishnaswami

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
Fredrik Lundh <eff...@telia.com> wrote:
> Samuel A. Falvo II wrote:
> > >umm. does using an explicit syntax tree turn Lisp
> > >into a statically typed language?
>
> > No, but I don't see what this has to do with the point I was trying
> > to make either.
>
> then I don't understand your point -- to compile
> things efficiently, you need to know what types
> your variables have.

There are actually a whole lot of optimizations that could be done,


but aren't, in the current Python interpreter.

For example, in the following code:

import operator

lst = []
for i in range(100):
lst.append(i**2 + i**2)

result = reduce(operator.add, lst)

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.

No, these analyses wouldn't help on super dynamic code, but it doesn't
need to to yield big speedups -- most Python code is in the simple
first-order form that is most amenable to analysis.

This is a lot of work, would greatly complicate the internal structure
of the Python implementation, and is a lot of work, and would somewhat
complicate interfacing with C, and is a lot of work, but it's
definitely possible. (*I* have no interest in doing this, not when it
would involve programming in C rather than Python, anyway.)

> in Python, you don't know that, no matter what tree structure or
> byte code format you use.

You don't have to win every game to make it to the championships. :)

Neel

Kragen Sitaker

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <slrn8cg5em...@garnet.armored.net>,

Samuel A. Falvo II <kc5...@garnet.armored.net> wrote:
>In article <usny1a...@sandia.gov>, taa...@sandia.gov wrote:
>>I saw a comparison of Lisp and Python at
>><http://www.norvig.com/python-lisp.html> which stated that Lisp can be
>>about 100 times faster than Python. I'm going to assume that this
>
>I think this has a lot to do with the "explicit syntax tree" that you build
>with LISP programs. Think about it -- the structure of LISP programs
>directly mirrors an equivalent semantic tree built with a traditional
>compiler, like C. As a result, the same types of optimizations that are
>possible with languages like C are possible with the likes of LISP too.

Well, the result of the syntax tree being explicit is that parsing is
faster and quicker to code. As you point out, it doesn't have anything
to do with the speed of the resulting code.

However, there are optimizations that are straightforward with C that
are not as straightforward with Lisp; Lisp is dynamically-typed, for
example.

>Many LISP environments compile to raw assembly language too, though I
>somehow doubt elisp does this.

It doesn't. It's also not 100 times faster than Python.

>There is little, if anything, preventing this type of optimizability in
>Python as well -- I recall a discussion from a friend of mine (Billy
>Tanksley) from before I regularly read this newsgroup, indicating a desire
>to switch from plain bytecodes to three-operand RISC-like, platform
>independent, fixed-width codes.

Well, Python is probably not as hard to optimize as Lisp and Scheme
dialects. But it certainly is not as easy as C.

>>Would the GUI be improved by using Tkinter or wxWindows?
>
>I would like to see GTK myself. Tkinter just "feels" wrong to me for some
>reason.

I take it you've developed applications with both? I'd be very
interested in reading brief case-studies of each. Even a paragraph on
each would be great.
--
<kra...@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. :)

Fredrik Lundh

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
Neel Krishnaswami <ne...@brick.cswv.com> wrote:
> There are actually a whole lot of optimizations that could be done,
> but aren't, in the current Python interpreter.
>
> For example, in the following code:
>
> import operator
>
> lst = []
> for i in range(100):
> lst.append(i**2 + i**2)
>
> result = reduce(operator.add, lst)
>
> 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.

</F>

Justin Sheehy

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to pytho...@python.org
kra...@dnaco.net (Kragen Sitaker) writes:

> Well, Python is probably not as hard to optimize as Lisp and Scheme
> dialects.

This is an interesting statement. On what do you base it?

-Justin

Thomas Bellman

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
"Fredrik Lundh" <eff...@telia.com> writes:

> Neel Krishnaswami <ne...@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

Kragen Sitaker

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <jm1y4.121$Lh9.18...@newsb.telia.net>,
Fredrik Lundh <eff...@telia.com> wrote:

>Neel Krishnaswami <ne...@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 Sitaker

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <vndg0ty...@camelot-new.ccs.neu.edu>,

Mostly ignorance; the following points come to mind, though:
- Python's numeric system is simpler. In Lisp, you can add two fixnums
and get a bignum, or not, depending on what the fixnums are.
- Python has explicit control structures; Scheme implementations
generally express control structures through tail-recursion (with
macros or otherwise), and require the compiler to recognize
tail-recursion. Although I am not yet initiated into the Mysteries
of the Continuation-Passing Compiler, it intuitively seems that loop
optimizations (e.g. strength-reduction, constant subexpression
elimination) should be more straightforward if it's obvious what is
and isn't a loop.

I'm interested to hear your thoughts.

Grant Edwards

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <pcoya7t...@math.ntnu.no>, Harald Hanche-Olsen wrote:

>| >[...] wildly minimalist, especially compared to Emacs.
>|
>| Compared to Emacs, what isn't?
>
>Windows? Or any other product from the same company?

Good point.

>Or, closer to home for most emacs users, what about X11?

One might argue that it would be hard to come up with a
portable, network-transparent windowing system that was much
simpler than X11, while it is possible to come up with a
simpler text editor than emacs. But, that assumes that the
only requirement for an emacs replacement is editing text...

--
Grant Edwards grante Yow! And furthermore,
at my bowling average is
visi.com unimpeachable!!!

Samuel A. Falvo II

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <Om9y4.1424$oN5.3...@tw11.nn.bcandid.com>, Kragen Sitaker wrote:
>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.

What about FORTH compilers? I don't see how Forth fits into this discussion
at all. Forth is an extremely static language, for all its dynamic
features. +, for example, will *only* produce meaningful results when fed
integers. As a result, it doesn't even make sense to perform type
inferencing with Forth. :)

Samuel A. Falvo II

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <nr_x4.613$oN5.1...@tw11.nn.bcandid.com>, Kragen Sitaker wrote:
>>>Would the GUI be improved by using Tkinter or wxWindows?
>>
>>I would like to see GTK myself. Tkinter just "feels" wrong to me for some
>>reason.
>
>I take it you've developed applications with both? I'd be very

Yes, but please understand that I'm talking from a USER'S standpoint, not a
programmer's standpoint. Tkinter just "feels" kludgey. GTK is more elegant
to use. Just my opinion.

Tkinter is probably easier to code for using Python, however. It's a design
tradeoff. :)

Aahz Maruch

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <slrn8cikie...@garnet.armored.net>,

Samuel A. Falvo II <kc5...@garnet.armored.net> wrote:
>In article <Om9y4.1424$oN5.3...@tw11.nn.bcandid.com>, Kragen Sitaker wrote:
>>
>>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.
>
>What about FORTH compilers? I don't see how Forth fits into this discussion
>at all. Forth is an extremely static language, for all its dynamic
>features. +, for example, will *only* produce meaningful results when fed
>integers. As a result, it doesn't even make sense to perform type
>inferencing with Forth. :)

I made the same mistake you did on my first reading, but a careful
reading shows that Kragen is implying that a FORTH compiler is easy.
--
--- Aahz (Copyright 2000 by aa...@netcom.com)

Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

"Along the lines of getting a massage, taking a hot bubble bath, and
swimming in a pool of warm, melted chocolate, can you give me some
innovative ways that you pamper yourself?"
"Spend three hours flaming stupid people on the Net." --Aahz

Andrew M. Kuchling

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
kra...@dnaco.net (Kragen Sitaker) writes:
> Mostly ignorance; the following points come to mind, though:
> - Python's numeric system is simpler. In Lisp, you can add two fixnums
> and get a bignum, or not, depending on what the fixnums are.

Python may move toward Lisp's behaviour in future versions. It's been
argued that it's confusing, particularly to new users, to have both
integers and long integers, two similar-looking types that can't
always be used in the same contexts. For example, in Python 1.5,
17L*[1,2] raises a 'TypeError: can't multiply sequence with non-int'
exception. (Fixed in the current CVS tree.) Post-1.6, or maybe only
in Py3K, instead of getting an OverflowError, you might silently get a
long integer result instead.

--
A.M. Kuchling http://starship.python.net/crew/amk/
I promised that this would be a frank record, so far as I can write one, and
God forbid that I should pretend that there is not a generous measure of spite
in my nature.
-- Robertson Davies, _Fifth Business_

Moshe Zadka

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to Justin Sheehy
On 10 Mar 2000, Justin Sheehy wrote:

> kra...@dnaco.net (Kragen Sitaker) writes:
>
> > Well, Python is probably not as hard to optimize as Lisp and Scheme
> > dialects.
>
> This is an interesting statement. On what do you base it?

I don't know any Lisp (I assume he means Common Lisp) but Scheme is
*almost* as dynamic as Python. What's more a reasonable subset of Python
(toss out eval, exec and looking too quizzically at sys.exc_info()) is
easily described via compilation to Scheme. Hence any Scheme optimization
can be a Python optimization.

--
Moshe Zadka <mza...@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html

Moshe Zadka

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to Grant Edwards
On Fri, 10 Mar 2000, Grant Edwards wrote:

> One might argue that it would be hard to come up with a
> portable, network-transparent windowing system that was much
> simpler than X11

Yes, but that argument wouldn't hold water: NeWS was such a system. The
only reason that it didn't kick X11's butt was that Sun was making the
same mistakes it makes today with Java while the good boys at MIT were
throwing out reference implementations to the public domain.

Sun employees will usually tell you it's DEC and other companies evil
politics: don't buy this. Sun were stupid, the world lost a good window
system.

Samuel A. Falvo II

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <8ablu8$5vv$1...@nntp6.atl.mindspring.net>, Aahz Maruch wrote:
>I made the same mistake you did on my first reading, but a careful
>reading shows that Kragen is implying that a FORTH compiler is easy.

You're correct. It took me at least eight re-readings of the message over
about 30 minutes to see how the sentence could be interpretted that way. :)

Grant Edwards

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
In article <Pine.GSO.4.10.10003102317130.4723-100000@sundial>, Moshe Zadka wrote:
>On Fri, 10 Mar 2000, Grant Edwards wrote:
>
>> One might argue that it would be hard to come up with a
>> portable, network-transparent windowing system that was much
>> simpler than X11
>
>Yes, but that argument wouldn't hold water: NeWS was such a system.

I've heard some good things about NeWS, but never new any
details. Isn't Apple's coming out with a new windowing system
based on display-PDF rather than the display-Postscript model?
That should make things even simpler. It's probably too late
for anything to replace X, no matter what its technical merits.

--
Grant Edwards grante Yow! I was giving HAIR
at CUTS to th' SAUCER PEOPLE
visi.com ... I'm CLEAN!!

Lloyd Zusman

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
Moshe Zadka <mos...@math.huji.ac.il> writes:

> On Fri, 10 Mar 2000, Grant Edwards wrote:
>
>