Python questions -> compiler and datatypes etc

[Paul Rubin]

<brueckd at tbye.com> writes:
> > I think the real answer to why there's no Python compiler is no one
> > has really wanted to write one.  Python's runtime semantics are pretty
> > similar to Lisp systems, and native-code Lisp compilers have existed
> > since the 1960's or maybe even earlier.  It might even be feasible
> > to adapt one to compile Python.
> 
> That'd be great. How about just creating a Python-to-Lisp translator? Then
> you could use whatever Lisp compilation tools are available (assuming, of
> course, that the performance of compiled Lisp is good enough to make the
> effort worthwhile).

That might be a reasonable basic approach (as opposed to, for example,
starting from Python bytecodes) but to do a good job, the compiler is
going to have to know some Python-specific things, like range and slice
objects, etc.  

Lisp compilers can make code as good as C compilers, but to optimize
that well, they usually need some programmer-supplied advice (similar
to pragmas) about object types etc.  A Python compiler will probably
want similar help from the programmer.

> It seems like the really hard part about translating Python to C, for
> example, is that you're moving "down" the dynamic language scale. But if
> you already have a compiler for a language that is near or higher on that
> scale, then somebody has already done a lot of the work for you.

C is pretty close to machine language, so compiling to C is similar to
compiling to assembly.  Some Lisp compilers (like KCL/AKCL) in fact
compile to C and then call an external C compiler to make a loadable
.o or .so file.

If you want to see how simple Lisp compilers work, see the
"metacircular evaluation" chapter of the very wonderful book
"Structure and Interpretation of Computer Programs" by H. Abelson and
G. J. Sussman.