Standardizing RPython - it's time.

[John Nagle]

On 10/11/2010 1:47 PM, Ryan Kelly wrote:
> On Mon, 2010-10-11 at 13:01 -0700, John Nagle wrote:
>> 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.
>
> A similar topic was recently discussed on the pypy-dev mailing list:
>
>    http://codespeak.net/pipermail/pypy-dev/2010q3/006170.html
>
>
> My interpretation is that the pypy devs are -0 on such a standardisation
> effort, as it would give them less flexibility in moulding rpython for
> their specific needs.  Adding features to rpython that make it better as
> a general-purpose programming language could actually make it *worse* as
> a specialised language for building pypy.
>
> OTOH, there does seem to be a growing interest in using rpython as a
> stand-alone language.  I've used it for some small projects and it
> worked out great.
>
> But the intersection of (people who want rpython as a general-purpose
> language) and (people who have the ability to make that happen) seems to
> be approximately zero at the moment...

     With Unladen Swallow looking like a failed IT project, a year
behind schedule and not delivering anything like the promised
performance, Google management may pull the plug on funding.
Since there hasn't been a "quarterly release" in a year, that
may already have effectively happened.

     All the schemes to speed up Python as defined by CPython seem to hit
a wall on speed improvement.  Some of the numeric benchmarks go faster
on implementations that don't box all numbers, but 2x seems to be about
as good as it gets, even with a JIT compiler.

				John Nagle