Standardizing RPython - it's time.

[John Nagle]

   It may be time to standardize "RPython".

   There are at least three implementations of "RPython" variants - PyPy,
Shed Skin, and RPython for LLVM.  The first two are up and running.
There's a theory paper on the subject:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.1457&rep=rep1&type=pdf

   All three have somewhat different restrictions:

PyPy's Rpython:
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html

Shed Skin:
file:///C:/Users/nagle/AppData/Local/Temp/shedskin-tutorial-0.3.html

Rpython for LLVM:
http://code.google.com/p/rpython/

So a language standardization effort, independent of CPython,
would be useful.

     All attempts to make the dialect defined by CPython significantly
faster have failed.  PyPy did not achieve much of a speed
improvement over CPython, and is sometimes slower.  Unladen Swallow
has not achieved a significant speedup, and is now a year behind
on quarterly releases, indicating that the project is in serious
trouble.  PyPy's RPython, Psyco, and Shed Skin, on the other hand,
all achieved order of magnitude or better speedups over CPython.
So this is the way to go for higher performance.

     RPython may be the future of Python, a "golden middle way" between
statically and dynamically typed languages.  A basic concept of RPython
is that it is declaration-free, like the CPython dialect, but limits
the ability to change the type of an object at run time.
Both PyPy's RPython and Shed Skin use type inference to determine
the types of objects.

     PyPy's RPython has the best defined set of restrictions.
Most of the restrictions are for speed, such as the unique-type
restriction.  A few simply reflect unimplemented features,
such as generators.  (Generators are not inherently inefficient.)

     A significant advantage of having a well defined set of
restrictions is that it encourages writing Python libraries which will
run under both RPython and CPython. This makes migration to a faster
system much easier.
					
					John Nagle