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 _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
