# [pypy-svn] r20464 - pypy/extradoc/talk/22c3

mwh at codespeak.net mwh at codespeak.net
Wed Nov 30 22:40:18 CET 2005

Author: mwh
Date: Wed Nov 30 22:40:17 2005
New Revision: 20464

Modified:
Log:
small tweaks and anglicizations.

==============================================================================
+++ pypy/extradoc/talk/22c3/techpaper.txt	Wed Nov 30 22:40:17 2005
@@ -14,7 +14,7 @@
Eventually, dynamic optimization techniques - implemented as another
translation aspect - should become robust against language changes.

-.. [#] http://www.python.org/doc/current/ref/ref.html
+.. [#] http://docs.python.org/ref

PyPy - an implementation of Python in Python
============================================
@@ -31,7 +31,7 @@
written in C (referred to throughout the PyPy documentation and source as
"CPython" [#]_).

-.. [#] http://python.org
+.. [#] http://www.python.org

Another central idea in PyPy is building the implementation in the form
of a number of independent modules with clearly defined and well tested API's.
@@ -51,7 +51,7 @@
========================

PyPy is not only about writing another Python interpreter.
-Traditionally, interpreters are written in some target platform language
+Traditionally, interpreters are written in a target platform language
like C/Posix, Java or C#.  Each such interpreter provides a "mapping"
from application source code to the target environment.  One of the
goals of the "all-encompassing" environments, like the .NET framework
@@ -64,20 +64,20 @@
Python interpreter for a specific target platform.  We have written a
Python interpreter in Python, without many references to low-level
details.  (Because of the nature of Python, this is already a
-complicated task, although not as much as writing it - say - in C.)
+complicated task, although not as much as writing it in - say - C.)
Then we use this as a "language specification" and manipulate it to
produce the more traditional interpreters that we want.  In the above
sense, we are generating the concrete "mappings" of Python into
lower-level target platforms.

-So far (fall 2005), we have already succeeded in turning this "language
+So far (autumn 2005), we have already succeeded in turning this "language
specification" into reasonably efficient C-level code that performs
basically the same job as CPython.  Memory management is inserted during
-this "translation" process.  It can be configured to use reference
+this *translation* process.  It can be configured to use reference
counting or not; thus we have already achieved two very different
-"mappings" of application Python code over C/Posix.  We have
-successfully translated our Python interpreter to the LLVM [#]_ target as
-well, and we are working on targeting higher-level environments like
+mappings of application Python code over C/Posix.  We have
+successfully also translated our Python interpreter into the LLVM [#]_ code,
+and we are working on targeting higher-level environments like
Java and Squeak.

In some senses, PyPy project's central component is not its
@@ -103,9 +103,9 @@
as far as language implementation is concerned - showing an approach
to the n * m * o problem that does not rely on standardization.

-This is the "meta-goal"; a more concrete goal worth mentioning at this
+This is the *meta-goal*; a more concrete goal worth mentioning at this
point is that language specifications can be used to generate cool stuff
-in addition to traditional interpreters -- e.g. Just-In-Time Compilers.
+in addition to traditional interpreters -- e.g. Just-In-Time compilers.

.. [#] http://llvm.cs.uiuc.edu/

@@ -167,7 +167,7 @@
- the *annotator* which performs type inference on the flow graph;

- the *typer* which, based on the type annotations, turns the flow graph
-  into one using only low-level, operations that fit the model of the
+  into one using only low-level operations that fit the model of the
target platform;

- the *code generator* which translates the resulting flow graph into
@@ -189,8 +189,7 @@
Python code at some point.  However, in the start-up phase, we are
completely free to use all kinds of powerful python constructs, including
metaclasses and execution of dynamically constructed strings.  However,
-when the initialization phase (mainly, the function
-objspace.initialize()) finishes, all code objects involved need to
+when the initialization phase finishes, all code objects involved need to
adhere to a more static subset of Python:
Restricted Python, also known as RPython.

@@ -234,7 +233,7 @@

\begin{figure*}[htbp]\begin{center}
\includegraphics{translation-greyscale-small.pdf}
-   overview over the translation process
+   overview of the translation process
\end{center}\end{figure*}

The complete translation process is described in more detail in the
@@ -271,12 +270,12 @@
written in Python to the resulting self-contained executable.

Our rather complete and Python 2.4-compliant interpreter consists
-of about 30'000-50'000 lines of code (depending on the way you
+of about 30,000-50,000 lines of code (depending on the way you
count code borrowed and adapted from other sources), with
-another 14'000 lines of unit tests.  If we include the tools,
+another 14,000 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 138'000
-lines of code and 32'000 lines of tests. Refer to
+standard library modules ported from C, PyPy is now 138,000
+lines of code and 32,000 lines of tests. Refer to
the statistics web page [#]_ for more detailed information.

.. [#] http://www.hpl.hp.com/personal/Hans_Boehm/gc/