[pypy-svn] r41511 - pypy/dist/pypy/doc

[arigo at codespeak.net]

Author: arigo
Date: Tue Mar 27 17:37:39 2007
New Revision: 41511

Modified:
   pypy/dist/pypy/doc/new-architecture.txt
Log:
Updates and rewrites to the High Level Goals section.


Modified: pypy/dist/pypy/doc/new-architecture.txt
==============================================================================
--- pypy/dist/pypy/doc/new-architecture.txt	(original)
+++ pypy/dist/pypy/doc/new-architecture.txt	Tue Mar 27 17:37:39 2007
@@ -32,14 +32,6 @@
 generator, should become robust against changes in the languages 
 implementated.
 
-.. XXX <arigo> (relating to an older version of the above)
-   the above wording looks nice, but somehow I end up missing all
-   these notions that were more explicit in the previous missing statement:
-   flexibility, variety of platforms large and small, custom Python
-   versions, memory and threading models, robustness against language
-   change, generating complete VMs, and the proof that it's really not
-   only for Python because we have other interpreters already...
-
 
 High Level Goals
 =============================
@@ -56,26 +48,26 @@
 for writing language implementations. 
 
 PyPy is experimenting with a more ambitious approach.  We are using a
-subset of a VHLL language, called RPython_, to specify languages
-with few references to and dependencies on lower level details,
-leaving it to the translation framework to add these as translation
-aspects and produce custom implementations for particular feature
-and platform configurations.  
-
-Particularly, we want to help avoiding having to write ``l * o * p``
-interpreters for ``l`` dynamic languages and ``p`` platforms
-with ``o`` crucial design decisions.  PyPy aims at having any
-one of these parameters changeable independently from each
-other:
+subset of the high-level language Python, called RPython_, in which we
+write languages as simple interpreters with few references to and
+dependencies on lower level details.  Our translation framework then
+produces a concrete virtual machine for the platform of our choice by
+inserting appropriate lower level aspects.  The result can be customized
+by selecting other feature and platform configurations.
+
+Our goal is to provide a possible solution to the problem of language
+implementors: having to write ``l * o * p`` interpreters for ``l``
+dynamic languages and ``p`` platforms with ``o`` crucial design
+decisions.  PyPy aims at having any one of these parameters changeable
+independently from each other:
 
-* ``l``: modify or replace the language we analyse and regenerate
-  a concrete interpreter for each target;
+* ``l``: the language that we analyze can be evolved or entirely replaced;
 
-* ``o``: tweak and optimize the translation process to produce 
+* ``o``: we can tweak and optimize the translation process to produce 
   platform specific code based on different models and trade-offs;
 
-* ``p``: write new translator back-ends to target 
-  different physical and virtual platforms.
+* ``p``: we can write new translator back-ends to target different
+  physical and virtual platforms.
 
 By contrast, a standardized target environment - say .NET -
 enforces ``p=1`` as far as it's concerned.  This helps making ``o`` a
@@ -85,41 +77,30 @@
 as far as language implementation is concerned - showing an approach
 to the ``l * o * p`` problem that does not rely on standardization.
 
-Particularly, we set ourselves the goal to *generate
-Just-In-Time Compilers* in addition to traditional
-interpreted implementations - an area of language
-implementation that is commonly considered very challenging
-because of the involved complexity. 
+The most ambitious part of this goal is to *generate Just-In-Time
+Compilers* in a language-independent way, instead of only translating
+the source interpreter into an interpreter for the target platform.
+This is an area of language implementation that is commonly considered
+very challenging because of the involved complexity.
 
 
 PyPy - the Python Interpreter 
 --------------------------------------------
 
-Our goal is to provide a full featured, customizable and fast Python
-implementation, written in a subset of Python itself, working on and interacting 
-with a large variety of platforms and allowing the quick introduction of
-new advanced language features. 
-
-The architecture and abstractions of PyPy's "Python language specification" 
-aim to enable new implementation and optimization features that 
-traditionally require pervasive changes in a language implementation 
-source code. 
-
-An important aspect of implementing Python in RPython is the high level of
-abstraction and compactness of the language. This allows an implementation
-that is, in many respects, easier to understand and play with than the one
-written in C (referred to throughout the PyPy documentation and source as
-"CPython").
-
-Another goal is to specify the language implementation in the form
-of a number of independent modules and abstractions, with clearly defined and 
-automatically tested APIs.  This eases reuse and allows experimenting with 
-variations and combinations of features. 
-
-Our Python language implementation architecture, however, also serves as a 
-key part for the translation framework:  we re-use its bytecode evaluator 
-to analyse RPython programs, PyPy's implementation language for specifying 
-language semantics and interpretation. 
+Our main motivation for developing the translation framework is to
+provide a full featured, customizable and fast Python implementation,
+working on and interacting with a large variety of platforms and
+allowing the quick introduction of new advanced language features.
+
+This Python implementation is written in RPython as a relatively simple
+interpreter, in some respects easier to understand than CPython, the C
+reference implementation of Python.  We are using its high level and
+flexibility to quickly experiment with features or implementation
+techniques in ways that would, in a traditional approach, require
+pervasive changes to the source code.  The archetypical example is
+reference counting in CPython: changing it to use another garbage
+collector would be a major undertaking, whereas in PyPy it is an issue
+orthogonal to the interpreter source code.
 
 
 PyPy Architecture