[pypy-dev] Question about pypy

[Laura Creighton]

Something major you are not mentioning is that pypy is a compiler
generator, and not a hand-written compiler for a particular language.
Thus we have PyProlog, which implements Prolog, and GameGirl which
implements the GameBoy language.  It's this architecture, in my opinion,
which makes PyPy advanced.  Just reading your sketch left me with the
impression that what you were going to present was a list of problems
that somebody wishing to hand-write a compiler for Python that generates
C would face.  The point of RPython is not that it makes the generation
of C code easier, though it does that, but that because its a much
higher level language which makes it possible to do things that would
be, if not impossible, at least a hugely harder than if it were all
written in C.

So, given an interpreter for any dynamic language, written in RPython,
you can now get your choice of garbage collectors, and a JIT thrown in
'for free' as it were.  You won't have to write one by hand for every
lanauge you are interested in -- including ones you design yourself
if your mind works that way.  So, for instance, nobody has written an
awk interpreter in RPython (at least as far as I know) but it wouldn't
be a very difficult thing to do.  And once that is done, you would
have a tracing awk compiler with a generational garbage collector --
which ought to be very fast.  No need to write those parts again for
your fast-awk.

Thus the challenge for RPython was to be high-level and expressive
enough to make it possible to write a pluggable gc, or a pluggable
JIT, or indeed the annotator itself, while still being static enough
that you can do whole program analysis in the first place.  That's the
'real tricky part', not as you write 'This type-agnostic bit is the
real tricky part because C requires all expressions to have a type,
while python does not'.  It's not the need to generate C that imposes
the limits on RPython -- indeed, in the past we have generated for the
JVM and the CLI -- and played with generating javascript and Lisp, its
the need to do whole program analysis.

Other note: Some of the problems in making a fast compiler for Python
are those it shares with any dynamic language.  Some are unique to
Python itself, and it might be a good idea to separate the two in your
presentation.

You might want to look at the slides of the talk that Armin gave this
March at Stanford. http://www.stanford.edu/class/ee380/Abstracts/110302.html

The whole thing was videotaped, I think you can find it here:
http://www.stanford.edu/class/ee380/winter-schedule-20102011.html

Good luck,
Laura Creighton