[pypy-dev] External RPython mailing list
william.leslie.ttg at gmail.com
Thu Sep 16 05:42:11 CEST 2010
On 16 September 2010 13:03, Saravanan Shanmugham <sarvi at yahoo.com> wrote:
> Either way, it looks like there i not much enthusiasm for porting Shedskin on
> PyPy and have pypy generate a compiler instead of an interpreter.
In a sense, it already does :). And of course translation is compilation, too.
> >From various threads on python.org as well pypy itself, I see a lot of interest
> in a compiler for a staticaly typed subset of python.
> I also feel that a statically typed subset of python can be faster than the
> dynamic superset.
It can be, there's nothing stopping you from dynamically compiling a
static language, and feeding back profiling information is easy too.
It's just probably not going to be *that* much faster to be of value
at the end of the day. Then again, the end of the day could be a long
> I can see why some might feel that RPython is not for general use and only for
> language development.
> But what totally surprises me though is that as a language developer, I would
> want RPython to be as flexible as possibile within feasibility of course.
You also have to look at it from the other perspective - that of
someone implementing a backend or translation aspect, such as a
garbage collector or a JIT compiler generator. This is my perspective
coming to pypy - I am experimenting with a range of optimisations
based on extensive region and effect analysis, and I fear rpython
already makes this difficult.
For example, the use of abstract interpretation to generate the
flowgraph IR means that you now have no information about which loop
is the 'outer' one, and that information can be useful in generating
heuristics. Similar things could be said about the JIT and generators,
which is not something I have looked at extensively, but dealing with
the generator case would have been implicit from the start if the IR
used a CPS transform to represent all instruction flow. In short:
rpython is complicated enough already.
It happens to do the job it was created for, but not a whole lot more
than that. It happens to be well suited to my experiments for two
unrelated reasons*. But I can't imagine choosing it to write extension
modules or inner loops - there are plenty of languages that do it
better, like cython, pyrex, D, cyclone, SML, etc.
* it's (memory) safe and the rffi is sane, particularly about letting
native code deal with rpython objects. And thanks to the pypy python
interpreter, there's a large body of code to test it on.
More information about the Pypy-dev