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

[cfbolz at codespeak.net]

Author: cfbolz
Date: Sat May 26 02:07:51 2007
New Revision: 43659

Modified:
   pypy/extradoc/talk/dyla2007/section2.txt
Log:
uh? for some reasons some parts of the document were duplicated


Modified: pypy/extradoc/talk/dyla2007/section2.txt
==============================================================================
--- pypy/extradoc/talk/dyla2007/section2.txt	(original)
+++ pypy/extradoc/talk/dyla2007/section2.txt	Sat May 26 02:07:51 2007
@@ -1,65 +1,3 @@
-
-XXX maybe drop something like that we want to look at the "life cycle" of a 
-successful open source dynamic language
-
-XXX define OO VM somewhere: common effort, usually backed by a large group of
-people or even company.  lots of engineering effort, high tuning, typical
-examples JVM, CLR (maybe parrot?)
-
-XXX describe open source and research general conditions somewhere
-  - low amount of workforce
-  - volunteers (in the case of open source)
- 
- - due to complicated semantics: simple bytecode oder AST interpreter. no
-   threaded code (ref) or other advanced interpreter technology or even dynamic
-   compilation
-
-
-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 not a simple 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. XXX expand a bit
-  - simpler threading models
-    - don't make single-threaded apps slower due to locks
-    - global locks
-    - green threading
-
- - C-level implementations of dyn language VMs have issues and trade-offs:
-     - reduced flexibility
-     - pressure to keep the implementation simple
-
- - wrapping with C libraries simple but tedious
-
-These listed 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") there is a number of additional
-implementations that want to fix some of the limitations of CPython. One of them
-is "Stackless Python" which is a fork of CPython that adds micro-threading
-capabilities to Python. One of the reasons for not incorporating 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 project which adds a JIT-compiler to CPython.
 XXX maybe drop something like that we want to look at the "life cycle" of a 
 successful open source dynamic language
 
@@ -125,7 +63,7 @@
 CPython was that it was felt that they would make the implementation too
 complex. Another implementation of the Python language is the Psyco project
 which adds a JIT-compiler to CPython. As all other reimplementations, Psyco
-contains the Pythonsemantics and needs to be kept synchronized with CPython
+contains the Python semantics and needs to be kept synchronized with CPython
 manually.
 
  - free threading attempts for Python
@@ -233,4 +171,7 @@
 issues are involved in such a decision. On the other hand deciding on one single
 object and execution model would not be an equally good fit for all languages.
 
-
+In the next section we are exploring a different approach for implementing
+dynamic languages that we hope is able to solve many of the problems of
+implementing a language, in particular the problem of an explosion of the number
+of implementations.