[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