On 16 September 2010 13:03, Saravanan Shanmugham <[email protected]> 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 way away. > 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. -- William Leslie _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
