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

[hpk at codespeak.net]

Author: hpk
Date: Wed Nov 30 14:01:51 2005
New Revision: 20432

Modified:
   pypy/dist/pypy/doc/architecture.txt
Log:
refined / clarified the "Meta Goals" (formerly "holy goal") section



Modified: pypy/dist/pypy/doc/architecture.txt
==============================================================================
--- pypy/dist/pypy/doc/architecture.txt	(original)
+++ pypy/dist/pypy/doc/architecture.txt	Wed Nov 30 14:01:51 2005
@@ -51,8 +51,8 @@
 .. _Stackless: http://stackless.com 
 
 
-PyPy - the Holy Goal
-====================
+PyPy - Meta Goals 
+========================
 
 PyPy is not only about writing another Python interpreter.
 Traditionally, interpreters are written in some target platform language
@@ -61,12 +61,12 @@
 goals of the "all-encompassing" environments, like the .NET framework
 and to some extent the Java virtual machine, is to provide standardized
 and higher level functionalities to language implementors.  This reduces
-the burden of having to write and maintain many interpreters (or
-compilers).
+the burden of having to write and maintain many interpreters or
+compilers.
 
 PyPy is experimenting with a different approach.  We are not writing a
 Python interpreter for a specific target platform.  We have written a
-Python interpreter in Python, without any reference to low-level
+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.)
 Then we use this as a "language specification" and manipulate it to
@@ -84,11 +84,12 @@
 well, and we are working on targeting higher-level environments like
 Java and Squeak.
 
-Thus we can argue that the PyPy project's central component is not its
-interpreter, but its configurable translator.  We think it is a good way
-to avoid writing ``n * m * o`` interpreters for ``n`` dynamic languages
-and ``m`` platforms with ``o`` crucial design decisions.  In PyPy any
-one of these can be changed independently:
+In some senses, PyPy project's central component is not its
+interpreter implementation, but its configurable translator.
+We think it provides a good way to avoid writing ``n * m * o``
+interpreters for ``n`` dynamic languages and ``m`` platforms
+with ``o`` crucial design decisions.  PyPy aims at having any
+one of these parameters changeable independently from each other:
 
 * we can modify or replace the language we interpret and just regenerate
   a concrete interpreter for each target;
@@ -98,18 +99,17 @@
 * we can tweak the translation process to produce low-level code based
   on different models and tradeoffs.
 
-By contrast, a standardized target environment -- say .NET -- just
-enforces ``m=1`` as far as it's concerned.  It also helps making ``o`` a
+By contrast, a standardized target environment -- say .NET -- 
+enforces ``m=1`` as far as it's concerned.  This helps making ``o`` a
 bit smaller by providing a higher-level base to build upon.  Still,
-speaking at least for myself (Armin), I believe that trying to enforce
-the use of one common environment is not necessary (and a bad idea in
-the first place).  PyPy's goal is to give weight to this claim (at least
-as far as language implementation is concerned), by showing an approach
+we believe that enforcing the use of one common environment 
+is not necessary.  PyPy's goal is to give weight to this claim - at least 
+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
 point is that language specifications can be used to generate cool stuff
-in addition to traditional interpreters -- e.g. JITs.
+in addition to traditional interpreters -- e.g. Just-In-Time Compilers. 
 
 
 Higher level picture