[pypy-svn] r80367 - pypy/extradoc/talk/stanford-ee380-2011

[arigo at codespeak.net]

Author: arigo
Date: Sun Feb 20 17:56:05 2011
New Revision: 80367

Modified:
   pypy/extradoc/talk/stanford-ee380-2011/abstract.txt
Log:
Updates: discussion with lac.

Modified: pypy/extradoc/talk/stanford-ee380-2011/abstract.txt
==============================================================================
--- pypy/extradoc/talk/stanford-ee380-2011/abstract.txt	(original)
+++ pypy/extradoc/talk/stanford-ee380-2011/abstract.txt	Sun Feb 20 17:56:05 2011
@@ -16,25 +16,25 @@
 language, using a (large) subset of Python called RPython.  On
 the other hand, we have a complex translation toolchain which is
 able to compile interpreters from RPython to efficient C code.
-(We also have experimental backends for producing JVM/.NET code.)
+(We also have experimental backends for producing JVM and .NET
+code.)
 
 There are two distinct benefits from keeping the interpreter and
 the translation toolchain separate.  On the one hand, we keep our
 interpreter simple, and we can easily write interpreters for
-other languages -- we have a Prolog interpreter and played with
-at least Smalltalk and JavaScript.
-On the other hand, it allows us to keep architectural choices
-independent from the original interpreter's source code, instead
-of getting stuck with one particular set of choices.  Our
-toolchain "weaves" into the final executable various aspects not
-present in the source of the interpreter: the object model,
-garbage collection (GC), the backend (C/JVM/.NET), and even the
-Just-in-Time Compiler (JIT).  For example, CPython's GC is stuck
-to be reference counting, while we offer a number of choices.  I
-will explain how this is done, and describe in particular the JIT
-Compiler, which is a "meta" tracing JIT --- it works for any
-language.
+other languages.  We have a complete Prolog interpreter and have
+at least played with versions for Smalltalk and Javascript.  On
+the other hand, the fact that our source interpreter does not
+contain any architectural choices makes for unprecedented
+flexibility.  Our toolchain "weaves" into the final executable
+various aspects including the object model, choice of garbage
+collection (GC), choice of backend (C/JVM/.NET), and even the
+Just-in-Time Compiler (JIT).  There are great practical benefits
+to this.  For example, CPython's GC is stuck with using reference
+counting, while we offer a number of choices.  I will explain how
+this is done, and describe in particular the JIT Compiler, which
+is a "meta" tracing JIT --- it works for any language.
 
-I will conclude by comparing PyPy with other projects, old and
-new: Squeak, CPython, Jython and IronPython, the Jikes RVM, as
-well as the various recent tracing JITs such as TraceMonkey.
+I will conclude by comparing PyPy to other projects, old and new:
+Squeak, CPython, Jython and IronPython, the Jikes RVM, as well as
+the various recent tracing JITs such as TraceMonkey.