[pypy-dev] Question about pypy

[Maciej Fijalkowski]

On Sun, Dec 4, 2011 at 9:07 PM, Alexander Golec
<alexgolecmailinglists at gmail.com> 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
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev