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

[arigo at codespeak.net]

Author: arigo
Date: Sun May 27 20:36:09 2007
New Revision: 43743

Modified:
   pypy/extradoc/talk/dyla2007/dyla.tex
Log:
Shrink shrink shrink the start of section 2.  It says less, but I think
that the point that we want implementations on top of OO VMs was made
in the introduction already.


Modified: pypy/extradoc/talk/dyla2007/dyla.tex
==============================================================================
--- pypy/extradoc/talk/dyla2007/dyla.tex	(original)
+++ pypy/extradoc/talk/dyla2007/dyla.tex	Sun May 27 20:36:09 2007
@@ -79,8 +79,8 @@
 techniques even if that entails lower execution speed. Similarly fragmentation
 (for example because of other implementations of the same language) is a
 problem because it divides available resources. All these points also apply to
-the implementation of domain-specific-languages where it is important to keep
-implementation effort small.
+the implementation of domain-specific languages where it is important to keep
+the implementation effort small.
 
 For these reasons writing a virtual machine in C is problematic because it
 forces the language implementer to deal with many low-level details. Limitations
@@ -125,71 +125,32 @@
 \section{Approaches to Dynamic Language Implementation}
 \label{sect:approaches}
 
-XXX the next paragraph is also the start of the introduction right now!
-
-Dynamic languages are traditionally implemented by writing a virtual
-machine for them in a low-level language like C, or in a language that
-can relatively easily be turned into C.  The machine implements an
-object model supporting the high level dynamic language's objects.  It
-typically provides features like automatic garbage collection.  Recent
-languages like Python, Ruby, Perl and JavaScript have complicated
-semantics which are most easily mapped to a simple interpreter operating
-on syntax trees or bytecode. Simpler languages like Lisp and Self
-typically have more efficient implementations based on just-in-time code
-generation.
-
-There are many good reasons for choosing C as an implementation language. It
-gives a decent base performance, is highly portable across different hardware
-architectures and operating system if some care is taken and it allows the reuse
-of many existing libraries.
-
-On the other hand the use of C comes with a set of problems. Since C has no ways
-to do automatic memory management and since the implemented languages are
-garbage collected, the VM needs to contain a garbage collector. Implementing a
-high-performance GC is a tedious task and so many implementations resort to
-relatively simple algorithms like mark-and-sweep or reference counting. Also the
-choice of garbage collector is fixed relatively early in the life of the project
-and then manifests itself throughout the complete VM source code. Thus it
-becomes extremely tedious to change it later.
-
-%A similar problem is the threading model the VM uses
-%  - simpler threading models
-%    - don't make single-threaded apps slower due to locks
-%    - global locks
-%    - green threading
-
-% - wrapping with C libraries simple but tedious
-
-These limitations of a C-based implementation often lead to more implementations
-of the language. For example in addition to the main C implementation of Python
-(``CPython'' \cite{cpy251}) there are a number of additional implementations
-that want to fix some of the limitations of CPython. One of them is ``Stackless
-Python'' \cite{stackless} which is a fork of CPython that adds micro-threading
-capabilities to Python. One of the reasons for not incorporating it back into
-CPython was that it was felt that they would make the implementation too
-complex. Another implementation of the Python language is the Psyco
-\cite{psyco-software}
-project which adds a JIT-compiler to CPython. As all other re-implementations,
-Psyco contains the Python semantics and needs to be kept synchronized with
-CPython manually.
-
-% - free threading attempts for Python
-
-As a language becomes more popular, yet another reason for different
-implementations emerges: People want to use it together with Java and C\#
-libraries and tools. Although it is in principle possible to do that by
-bridging the C-VM with the respective VMs of these languages (for example the
-``PythonNet'' project \cite{pythonnet} that brigdes CPython with a .NET VM)
-this is an incomplete solution since it prevents many use-cases.
-Therefore in the end implementations of the dynamic language on top of the
-object-oriented VMs are created to properly integrate with the complete
-environment.
+\def\implname#1{\emph{#1}}
 
+The fact that limitations of a C-based implementation of a dynamic
+language leads to the emergence of additional implementations is clear
+in the case of Python.  The reference implementation, \implname{CPython}
+\cite{cpy251}, is a simple recursive interpreter.  \implname{Stackless
+Python} \cite{stackless} is a fork that adds micro-threading
+capabilities to Python. One of the reasons for not incorporating it back
+into CPython was that it was felt that they would make the
+implementation too complex. Another implementation of the Python
+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} one for
+.NET.  All of these need to be kept in sync with the relatively fast
+evolution of the language.
+
+With the emergence of .NET and the JVM as interesting language
+implementation platforms, an argument that is sometimes made is that
+communities should only develop an implementation of their language for
+one of these platforms.\footnote{Preferably the argument author's favourite
+one.}
 
 \subsection{Assessing the Advantages of Implementing a Language on Top of OO
 VMs}
 
-Implementing a language on top of an OO VM is in many ways easier than
+Implementing a language on top of an existing OO VM is in many ways easier than
 implementing it in C. Let's take a look at the advantages that are usually
 cited for basing a
 language implementation of a dynamic language on a standard object oriented
@@ -249,7 +210,7 @@
 \item
 \emph{Better performance:} So far it seems that performance of highly dynamic
 languages is not actually significantly improved on OO VMs. 
-Jython\footnote{Python on the Java VM} is around 5
+Jython is around 5
 times slower than CPython, for IronPython\footnote{Python on .NET, which
 gives up on some features to improve performance}
 the figures vary but it is mostly