[pypy-svn] r43762 - pypy/extradoc/talk/dyla2007

arigo at codespeak.net arigo at codespeak.net
Sun May 27 23:48:11 CEST 2007


Author: arigo
Date: Sun May 27 23:48:10 2007
New Revision: 43762

Modified:
   pypy/extradoc/talk/dyla2007/dyla.pdf
   pypy/extradoc/talk/dyla2007/dyla.tex
Log:
Avoid "in sync" and "out of sync".


Modified: pypy/extradoc/talk/dyla2007/dyla.pdf
==============================================================================
Binary files. No diff available.

Modified: pypy/extradoc/talk/dyla2007/dyla.tex
==============================================================================
--- pypy/extradoc/talk/dyla2007/dyla.tex	(original)
+++ pypy/extradoc/talk/dyla2007/dyla.tex	Sun May 27 23:48:10 2007
@@ -136,7 +136,7 @@
 language is \implname{Psyco} \cite{psyco-software}, which adds a
 JIT-compiler to CPython.  Finally, \implname{Jython} is a
 re-implementation for the Java VM and \implname{IronPython} for
-the CLR.  All of these need to be kept in sync with the relatively fast
+the CLR.  All of these need to be kept synchronized with the relatively fast
 evolution of the language.
 
 With the emergence of the CLR and the JVM as interesting language
@@ -295,7 +295,7 @@
 virtual machine.  It also gives other benefits that we will describe --
 mostly in term of flexibility.  Most importantly, it lets a
 community write a single source implementation of the language, avoiding
-the time-consuming task of keeping several of them in sync.  The single
+the time-consuming task of keeping several of them synchronized.  The single
 source can be used to generate either custom VMs for C-like
 environments or interpreters running on top of OO VMs.  This makes it
 practical to experiment with large changes to the language and with
@@ -497,8 +497,9 @@
 with the necessary support code and the rest of the regular interpreter.
 
 This result was one of the major goals and motivations for the whole
-approach.  By construction, the JIT does not get out of sync when the
-language evolves, and any code written in the dynamic language runs
+approach.  By construction, the JIT stays synchronized with its VM
+and with the language when it evolves,
+and any code written in the dynamic language runs
 correctly under the JIT.  Some very simple Python examples run more than
 100 times faster.  At the time of this writing this is still rather
 experimental, and the techniques involved are well beyond the scope of
@@ -515,8 +516,8 @@
 \begin{itemize}
 \item \emph{Do not write dynamic language implementations ``by hand''.}
 Writing them more abstractly, at a higher level, has primarily only
-advantages, among them the avoidance of a proliferation of implementations
-growing out of sync.  Writing interpreters both flexibly and efficiently
+advantages, among them the avoidance of a proliferation of diverging
+implementations.  Writing interpreters both flexibly and efficiently
 is difficult and meta-programming is a good way to achieve it.
 Moreover, this is not incompatible with targeting and benefiting from
 existing high-quality object-oriented virtual machines like those of the Java and .NET.



More information about the Pypy-commit mailing list