Thanks for this point. I think this tied together my understanding of the the purpose of rpython as a framework. Where is the distinction between rpython as a language and rpython as a compiler generator? I presume this is covered in the 'Compiling Dynamic Language Implementations' paper?
Alex On Dec 4, 2011, at 8:06 AM, Laura Creighton wrote: > 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
