[pypy-svn] r51896 - pypy/extradoc/proposal

[lac at codespeak.net]

Author: lac
Date: Wed Feb 27 10:25:02 2008
New Revision: 51896

Modified:
   pypy/extradoc/proposal/openjdk-challenge.txt
Log:
Fix typos and minor grammatical errors; whack one extremely clumsy sentence;
and add a few XXX:s for ideas I have for improvement


Modified: pypy/extradoc/proposal/openjdk-challenge.txt
==============================================================================
--- pypy/extradoc/proposal/openjdk-challenge.txt	(original)
+++ pypy/extradoc/proposal/openjdk-challenge.txt	Wed Feb 27 10:25:02 2008
@@ -9,8 +9,8 @@
 we mention other languages implementations?)
 
 PyPy is divided into two main parts: the Python interpreter, which
-implements the Python language and its written in RPython_, and the
-Translation Toolchain (TT), which transforms and translates programs
+implements the Python language and is written in RPython_, and the
+Translation Toolchain (TT), (XXX: written in Python?) which transforms and translates programs
 written in RPython into the final executables.  RPython is a subset of
 Python specifically designed to allow the TT to analyze RPython
 programs and translate them into lower level, very efficient
@@ -22,17 +22,18 @@
 standard C/Posix environment, on the CLI or on the JVM.
 
 It is important to underline that the job of the TT is not limited to
-the translation into an efficient executable, but it actively
-transform the source interpreter by adding new features and
+translation into an efficient executable, but it actively
+transforms the source interpreter by adding new features and
 translation aspects, such as garbage collection, stackless
-capabilities, etc. (XXX: link).
+capabilities, etc. (XXX: link) (XXX: not sure stackless is well known,
+say microthreading instead?? mention proxying or security aspects??).
 
 The most exciting feature of the TT is the ability to automatically
 turn the interpreter into a JIT compiler that exploits partial
 evaluation techniques to dynamically generate efficient code.
 
 Currently, the PyPy JIT works only in conjunction with the C backend;
-early results are very good, since the resulting Python interpreter
+early results are very good, the resulting Python interpreter
 can run numeric intensive computations at roughly the same speed of C
 (XXX: link).
 
@@ -90,12 +91,16 @@
 write completely new code.
 
 If the project goes to completion, the code developed will be
-integrated into the PyPy codebase; if Sun requires to release the code
+integrated into the PyPy codebase; if Sun requires us to release the code
 under the SCA (thus sharing the copyright between the original author
 and Sun itself), we will send to Sun a document in unified diff format
 that extensively shows all and sole lines of code on which Sun will
 have the copyright.
 
+PyPy is already licensed under the extremely permissive MIT license,
+so there are no legal copyright barriers preventing us from sharing
+code in such a way.
+
 
 Project completion
 ------------------
@@ -126,20 +131,22 @@
 Relevance to the community
 --------------------------
 
-Recently the community showed a lot of interests in dynamic languages
-on top of the JVM.  Even if right now Jython is the only usable
-implementation of Python for the JVM, PyPy can potentially become the
+Recently the community has shown a lot of interest in dynamic languages
+which run
+on top of the JVM.  Even if currently Jython(XXX: link) is the only usable
+implementation of Python for the JVM, PyPy has the potential to become the
 reference implementation in the future.  
 
-To have a working JIT for the JVM is an important step to make PyPy
-the fastest Python for the JVM ever.  Moreover, due to the innovative
-ideas implemented by PyPy, there are chances that Python could become
-the fastest dynamic language that run on the top of the JVM.
+To have a working JIT for the JVM is an important step towards making PyPy
+the fastest Python for the JVM, ever.  Moreover, due to the innovative
+ideas implemented by PyPy, it is possible (XXX: likely?) that Python could become
+the fastest dynamic language that runs on the top of the JVM.
 
 Finally, PyPy is not limited to Python: it is entirely possible to
 write interpreters for languages other than Python and translate them
-with the TT; as a proof of concept, PyPy already contains partial
-implementations of Prolog, JavaScript, Scheme and Smalltalk.
+with the TT; as a proof of concept, PyPy already contains 
+fairly complete implementations of Prolog and Smalltalk, as well
+as partial implementations of JavaScript and Scheme. (XXX: did I overstate things?)
 
 Since the JIT generator is independent of the Python languages, it
 will be possible to automatically add a JIT compiler to every language
@@ -164,15 +171,15 @@
   - `this paper`_ shows how this technique is exploited to write an
     efficient implementation of EcmaScript which runs on top of the JVM;
 
-  - JRuby also come with a JIT compiler that dynamically translates
-    ruby code into JVM bytecode; the difference with the PyPy approach
-    is that JRuby doesn't exploit type information that are known only
+  - JRuby also comes with a JIT compiler that dynamically translates
+    Ruby code into JVM bytecode, however, unlike PyPy
+    JRuby doesn't exploit type information that is known only
     at runtime to produce specialized, efficient versions of the
     function; moreover, while the JRuby JIT is hand-written, the whole
     goal of the PyPy JIT generator is to generate it automatically
     from the intepreter;
 
-  - in the .NET world, IronPython also emit code dynamically to
+  - in the .NET world, IronPython also emits code dynamically to
     optimize hot spots, but not in a pervasive way as JRuby or PyPy.
 
     XXX (arigo) I'm confused by the previous sentence.  I thought