[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

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
+* 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
-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