[pypy-svn] r48264 - pypy/extradoc/talk/roadshow-ibm

lac at codespeak.net lac at codespeak.net
Sat Nov 3 09:06:32 CET 2007


Author: lac
Date: Sat Nov  3 09:06:31 2007
New Revision: 48264

Modified:
   pypy/extradoc/talk/roadshow-ibm/talk.txt
Log:
Latest attempt at 3 slides covering 'motivation', except that it doesn't quite do that any more.  This may be ok.


Modified: pypy/extradoc/talk/roadshow-ibm/talk.txt
==============================================================================
--- pypy/extradoc/talk/roadshow-ibm/talk.txt	(original)
+++ pypy/extradoc/talk/roadshow-ibm/talk.txt	Sat Nov  3 09:06:31 2007
@@ -10,41 +10,51 @@
 
 PyPy is a tool-chain with a *new paradigm* for building interpreters:
 
-It challenges the following commonly-held assumptions about the
+It challenges commonly held assumptions about the
 construction of interpreters for dynamic languages.
 
-* Speed
+What we Reject
+==============
+* Interpreters for Dynamic Languages must be slow
 
-* Maintainability
+* Fast, Maintainable, Flexible -- pick one
 
-* Flexibility
+* C is the most appropriate language for implementing interpreters.
 
-* ...and ease of implementation
+* C++ is the most appropriate language for implementing interpreters.
 
-What is PyPy?
-==============
+* Requiring type-hints everywhere, thus turning your dynamic language
+  into a static one, on the sly
 
-* A fun and challenging  open source project with many contributors
+What we insist upon
+===================
 
-* An open source implementation of Python  (written in Python)
+* real source code portability between different target implementations
 
-* Dec 2004 - March 2007: a research project funded by the European
-  Union and companies.
+* support for an actual existing dynamic language, not an academic toy
 
-Motivation
-=============
+* support for the complete language, not a subset
+
+* The interpreter we write should be free of low-level details as possible
 
-Conventional interpreters face hard trade-offs:
-*speed - maintainability - flexibility*
+* the ability to experiement with all aspects of the compiler, including
+  garbage collection strategies, threading models, security models
+
+* fun
+
+Implications?
+=============
 
-A lot of decisions are hard-coded pervasively, improvements
-and evolution are hampered (e.g. psyco, stackless)
+* type analysis must be performed on live code objects, not dead source trees
 
-Lots of duplication of effort to cover many platforms (C, Java, .NET).
+* parts of the interpreter must be written in a static manner.
 
-*It should be possible to do better.*
+* Generate compilers using partial evaluation techniques.  Don't write them
+  by hand!
 
+* Build a toolchain with pluggable components, for e.g. garbage collection
 
+* The translation framework can be reused by _any_ dynamic language!
 
 Translation aspects
 ========================



More information about the Pypy-commit mailing list