On Sun, Dec 4, 2011 at 9:07 PM, Alexander Golec <[email protected]> wrote: > 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?
There is no distinction between rpython as a language and rpython as a compiler generator. it's just that rpython is a good language to write dynamic language VMs in (or we think so, works fine so far). It's also not really truly for compilers, just for VMs. > > 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 _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
