[pypy-svn] r12650 - pypy/dist/pypy/documentation

[hpk at codespeak.net]

Author: hpk
Date: Fri May 20 19:16:51 2005
New Revision: 12650

Modified:
   pypy/dist/pypy/documentation/architecture.txt
Log:

tweaking the introduction part of the architecture 
document.  I always found that this was mixing 
current status and higher level ideas too much. 
hope you like it. 



Modified: pypy/dist/pypy/documentation/architecture.txt
==============================================================================
--- pypy/dist/pypy/documentation/architecture.txt	(original)
+++ pypy/dist/pypy/documentation/architecture.txt	Fri May 20 19:16:51 2005
@@ -30,45 +30,52 @@
 It has become a tradition in the development of computer languages to
 implement each language in itself. This serves many purposes. By doing so,
 you demonstrate the versatility of the language, and its applicability for
-large projects.  A compiler/interpreter is close to as complex as software
-ever gets.
-
-The PyPy project aims to do this for Python_ and has made some significant
-progress. In a number of one week sprints, attracting approximately
-10 developers each, we made an almost complete implementation of Python in
-Python. Currently it is rather slow, benchmarking at a factor 2000 times
-slower than regular Python (henceforth referred to as CPython).
-
-For some time now the bleeding edge PyPy work has been focused on generating
-reasonably efficient C code from the source of PyPy, thereby reducing the
-speed penalty.  This goal is no longer far away.
-
-Later in the project, we will introduce optimizations (following the ideas
-of Psyco_ and Stackless_) that should make PyPy run faster than CPython.
+large projects.  Writing compilers and interpreters are among the most 
+complex endeavours in software development. 
 
 An important aspect of implementing Python in Python is the high level of
-abstraction and compactness of the language. This yields an implementation
+abstraction and compactness of the language. This allows an implementation
 that is, in some respects, easier to understand and play with than the one
-done in C.
+done in C.  Actually, the existing CPython implementation is mostly 
+well written and it is often possible to manually translate according
+CPython code to PyPy by just stripping away many low level details. 
 
 Another carrying idea in PyPy is to build the implementation in the form
 of a number of independent modules with clearly defined and well tested API's. 
 This eases reuse and allows experimenting with multiple implementations 
 of specific features.
 
-Our rather complete and 2.3-compliant interpreter is about 22000 lines of
-code, with another 7000 lines of unit tests.  If we include the tools, the
+Later in the project, we will introduce optimizations, following the ideas
+of Psyco_ and Stackless_, that should make PyPy run Python programs 
+faster than CPython.
+
+.. _Python: http://www.python.org/doc/current/ref/ref.html
+.. _Psyco: http://psyco.sourceforge.net
+.. _Stackless: http://stackless.com 
+
+Status of the implementation (May 2005)
+---------------------------------------
+
+In a number of one week sprints, attracting approximately 10 developers each,
+we made an almost complete implementation of Python in Python. Currently it is
+slow, benchmarking at a factor 2000 times slower than regular Python
+(henceforth referred to as CPython). This was expected because running a
+bytecode interpreter on top of CPython obviously imposes a
+double-interpretation penalty. 
+
+Our rather complete and Python 2.3-compliant interpreter is about 22000 lines 
+of code, with another 7000 lines of unit tests.  If we include the tools, the
 parts related to code analysis and generation, and the standard library
 modules ported from C, PyPy is now 55000 lines of code and 20000 lines of
 tests.
 
-We also pass a number of CPython's own tests, including 90% of the "core"
-tests not depending on C extension modules (most of the remaining 10% are
+PyPy already passes a lot of CPython's own regression tests, including 90% of the 
+core tests not depending on C extension modules (most of the remaining 10% are
 arguably dependant on very obscure implementation details of CPython).
 
-.. _Python: http://www.python.org/doc/current/ref/ref.html
-.. _Psyco: http://psyco.sourceforge.net
-.. _Stackless: http://stackless.com 
+For some time now the bleeding edge PyPy work has been focused on generating
+reasonably efficient C code from the source of PyPy, thereby reducing the
+speed penalty.  This goal is no longer far away.
 
 
 Higher level picture