[pypy-dev] Question on the future of RPython

[Paolo Giarrusso]

> You should seriously read and try to understand the e-mails that you reply
> to, instead of top-posting them away.

Stefan, there are different ways to argue the same valid thing, and
the way you chose is IMHO counterproductive for you - the only result
is offensive comments.
Also, while I seldom top-post, especially in public forums/MLs, IIRC
several PyPy contributors routinely top-post, and I see some sensible
arguments (see http://en.wikipedia.org/wiki/Posting_style#Top-posting).

Saravanan, a small part of the issue is that many people consider top
posting inappropriate and/or lame (for instance
http://www.caliburn.nl/topposting.html). Be aware of that risk if you
top-post. And please, never claim it increases readability - it makes
your post only readable if you read the whole thread. Non-crappy email
clients highlight differently the new text from the quoted text,
making the former easy to find.

In particular, by top-posting you never address the comments which
explain why merging does not necessarily make sense (like some of
mine), or the ones which argue it's a bad idea (like last Amaury's
mail). Interleaved replying brings instead to point-by-point answers.

See other comments below.
On Fri, Sep 3, 2010 at 11:30, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Saravanan Shanmugham, 03.09.2010 11:11:
>> From: Jacob Hallén
>> I have heard repeatedly in this alias that PyPy's RPython is very difficult to
>> use.
This alias?? You mean this _thread_, don't you?
>> I have also heard here and elsewhere that Shedskin fast and is great for what it
>> does i.e. translate its version of Restricted Python to C++.

>> Which then begs the question, would it make sense for PyPy to adopt Shedskin to
>> compile its PyPy RPython code into C++/binary.

The answer is already implicit in one of my previous emails, and is a
very clear "no, unless considerable extra merging effort is done,
which might be more than the effort to make the RPython compiler
better than Shedskin". I paste a relevant subset of that mail at the
end; while I can believe that you have read it, I often do not
understand all the implications of what I read the first time, if
that's complex, like it is for everybody, so do not be offended if I
suggest you to re-read it again.

A similar, more detailed argument is discussed by Amaury Forgeot d'Arc
in an email where he replies to you.

In other mails, you write that:

> I just don't see any logical reasons [against the merger], thats all. And I haven't heard any on this
> thread either.

> no one has necessarily claimed logical impossibility on why this may not work.

which strikes me as _wrong_. The mails I mentioned explain why there
are different design goals - Amaury, who knows more about Shedskin
than me, explained why it is less general. That's already an answer
for me.
Of course, this does not prove impossibility, it only suggests that it
may be not a good idea to merge the projects. You shouldn't care about
logical impossibility, which makes _NO SENSE_ in such questions in
software engineering; what is possible and bad makes little sense.

If you meant "nobody claimed that this is necessarily a bad idea",
then I agree. We believe there's no obvious way to combine the
projects; anybody, including you, is welcome to address the specific
issues and find some clever solution. You didn't even scratch them,
yet. And while you claimed experience with using the projects, or
reading their documentation, it is not clear at all that you
understand their internals, and this is required to address these
problems.

The only idea which makes some sense is that instead of starting the
development of Shedskin, the author could have tried achieving the
same results improving RPython, fixing its error messages and so on.
However, I can imagine a ton of possible reasons for which he might
have consciously decided to do something else. The keyword here is
"design tradeoff": a design choice can make a product better in some
respects and worse in other ones. Shedskin is less flexible, but
possibly this gives technical advantages which are important. That's
the same thing as explained below.

Best regards

=====

=> Do different goals cause _incompatible_ design/implementation choices?
Currently, static typing versus global type inference seems to be
already a fundamental difference. Modular type inference, if
polymorphic (and I guess it has to be), would require using boxed or
tagged integers more often, as far as I can see.

RPython is intended to be compiled to various environments, with
different variations (choose GC/stackful or stackless/heaps of other
choices), and its programmers are somewhat OK with its limitations; it
has type inference, with its set of tradeoffs. This for instance
prevents reusing shedskin, and probably even prevents reusing any of
its code.
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/