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

[arigo at codespeak.net]

Author: arigo
Date: Wed May 23 23:03:22 2007
New Revision: 43591

Modified:
   pypy/extradoc/talk/dyla2007/dyla.txt
   pypy/extradoc/talk/dyla2007/outline.txt
Log:
Intermediate check-in (this is in a rather inconsistent state)


Modified: pypy/extradoc/talk/dyla2007/dyla.txt
==============================================================================
--- pypy/extradoc/talk/dyla2007/dyla.txt	(original)
+++ pypy/extradoc/talk/dyla2007/dyla.txt	Wed May 23 23:03:22 2007
@@ -28,10 +28,11 @@
 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 and Perl 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.
+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.
 
 The efforts required to build a new virtual machine are relatively
 important.  This is particularly true for languages which are complex
@@ -43,26 +44,32 @@
 an Open Source community with a limited amount of resources.  The same
 constraint can be found in many academic projects.
 
-However, there is a recent trend that enters in conflict with the goal
-of having to maintain essentially a single, simple enough implementation
-for a given programming language.  This trend is to build an
-implementation of the language on top of another virtual machine, like
-the Java VM or the .NET one.
+Limitations of C implementations are XXX (limited GC, limited speed,
+C-only platforms, lack of flexibility).
 
-As in the case of Python and Ruby, this results in multiple
+To address some of these issues, a recent trend is to build an
+implementation of the language on top of another virtual machine.  Java
+(and increasingly .NET) provides well-tuned object-oriented virtual
+machines which offer many features that are of interest to all
+programmers including language implementors (a higher level of
+expression, automatic memory management, good just-in-time compilers,
+richer libraries...).  They also provide a higher level "base object
+model", which enables better cross-language integration: a Jython
+program, for example, can directly import Java classes and vice-versa.
+
+This trend enters in conflict with the goal of having to maintain
+essentially a single, simple enough implementation for a given
+programming language: as the language becomes popular, there will be a
+demand for having it run on various platforms - high-level VMs as well
+as C-level environments.
+
+In the case of Python and Ruby, this resulted in multiple
 implementations of the language, with an oldest custom VM written in C
 which is the "official" version in the sense that its evolution defines
 the evolution of the language itself.  The other implementations -
 Jython and JRuby on the JVM, IronPython and IronRuby on .NET -
 ultimately need to be tediously kept up-to-date.
 
-Java (and increasingly .NET) provides well-tuned object-oriented virtual
-machines which offer many features that are of interest to all
-programmers including language implementors (a higher level of
-expression, automatic memory management, richer libraries...).  They
-also provide a higher level "base object model", which enables better
-cross-language integration: a Jython program can directly import Java
-classes and vice-versa.
 
 What is the best way to implement dynamic languages?
 ----------------------------------------------------

Modified: pypy/extradoc/talk/dyla2007/outline.txt
==============================================================================
--- pypy/extradoc/talk/dyla2007/outline.txt	(original)
+++ pypy/extradoc/talk/dyla2007/outline.txt	Wed May 23 23:03:22 2007
@@ -3,6 +3,21 @@
 ~~~~~
 
 
+
+If we write VMs by hand:
+
+* let's say we pick C, then (typical limitations: GC, perf, ...)
+
+* let's say we pick one OO VM, then advantages (GC, tools, interop)
+  but some of them disputable (perf, object model may mismatch)
+
+* above all that, implementation proliferation problem
+
+
+=> Metaprogramming is good
+
+
+
 Introduction
 ============
 
@@ -29,12 +44,13 @@
   * implementations should be generated - don't write VMs by hand any more
 
 
-The OO VM Arguments
+Writing VMs by hand
 ===================
 
 - Writing dynamic language implementations in an OO VM gives advantages
   over writing custom VMs in C.  Supposedly we get:
   * more interoperability than the C level
+  * cross-platform portability
   * better tools
   * better implementation of low-level issues like GC
   * better performance
@@ -55,7 +71,8 @@
     it gives a higher-level language but also an imposed model in
     which concepts must be mapped, which may be anywhere from easy
     to mostly impossible depending on the language we want to implement
-    (ref... e.g. bad functional languages support for .NET?)
+    (ref... e.g. bad Prolog on .NET and JVM)
+  * "cross-platform portability": XXX
 
 - Not all arguments are bogus: we get better tools and GCs in theory,
   and interoperability with the rest of the VM
@@ -108,13 +125,17 @@
 
 - Don't write dynamic language implementations "by hand"
   * writing them more abstractly at a high level has mostly only advantages
+  * we can still reuse existing good OO VMs
 
 - Don't write VMs by hand any more
   * certainly not language-specific VMs
-  * but even general-purpose OO VMs have trade-offs
+  * but even general-purpose OO VMs have trade-offs and are too much work
+    unless you have the necessary resources
 
 - Let's write more metaprogramming translation toolchains
-  * diversity is good (high level SSI good as starting base) 
+  * diversity is good
+  * very large, mostly unexplored design space (some of PyPy's choices will
+    probably turn out to not be optimal)
   * ultimately a better investment of efforts than writing general-purpose VMs