[pypy-svn] r57878 - pypy/extradoc/talk/osdc2008

[mwh at codespeak.net]

Author: mwh
Date: Sat Sep  6 10:56:18 2008
New Revision: 57878

Modified:
   pypy/extradoc/talk/osdc2008/paper.txt
Log:
more copy-paste-adaptation of my slides

Modified: pypy/extradoc/talk/osdc2008/paper.txt
==============================================================================
--- pypy/extradoc/talk/osdc2008/paper.txt	(original)
+++ pypy/extradoc/talk/osdc2008/paper.txt	Sat Sep  6 10:56:18 2008
@@ -80,10 +80,57 @@
 PyPy's Big Idea And The PyPy Meta-Platform
 ------------------------------------------
 
+ * Take a description of the Python programming language
+ * Analyze this description, for example:
 
-The LxOxP problem
------------------
+  * Decide whether to include stackless- or psyco-like features
+  * Decide which GC to use
+  * Decide the target platform
+
+ * Translate to a lower-level, efficient form
+
+XXX Get copy of that image in here somehow.
+
+We chose to specify the Python language by writing an implementation
+if Python in a restricted subset of Python that is amenable to
+analysis.  This let us write unit tests for parts of our
+specification/implementation before we had the whole thing done, and
+also let us test the whole specification/implementation before the code
+that analysed the specification/implementation was written.
+
+The code that does the analysis -- now revealed in its true colours to
+basically be a compiler for this restricted subset of Python -- is
+generally referred to as the 'translator.  It is unlike most compilers
+takes as input live Python objects (as opposed to source code).  It
+abstractly interprets the bytecode of functions to produce flow
+graphs.  Further layers of abstract interpretation perform more
+analysis and gradually reduce the level of abstraction before finally
+C or other source code is generated
+
+The *LxOxP* problem
+-------------------
+
+We'd written this compiler framework, with only one expected
+non-trivial input (our Python interpreter).  We realized that it would
+be suitable for implementations of other dynamically-typed programming
+languages.  Now have implementations of Prolog, JavaScript and Scheme
+(to varying extents)
+
+This leads to one of PyPy's meta-goals, ameliorating the so-called
+LxOxP problem: given
+
+  * L dynamic languages
+  * O target platforms
+  * P implementation decisions
+
+we don't want to have to write LxOxP different interpreters by hand.
+PyPy aims to reduce this to an L+O+P problem:
+
+ * Implement L language front-ends
+ * Write backends for O platforms
+ * Take P implementation decisions
 
+Then let the magic of PyPy(TM) tie it all together :-)
 
 Status
 ------