> 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 <[email protected]> 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/ _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
