[pypy-svn] rev 1090 - pypy/trunk/doc
lac at codespeak.net
lac at codespeak.net
Sun Jul 6 23:35:43 CEST 2003
Author: lac
Date: Sun Jul 6 23:35:43 2003
New Revision: 1090
Modified:
pypy/trunk/doc/oscon2003-paper.txt
Log:
Improved the text. Still cannot get headings that I like. I would like lots
of my headings to be a lot smaller than what we get now. Goals could be
big, but I want the small headings small. And this is hard going. I will
see if sleep improves me.
Modified: pypy/trunk/doc/oscon2003-paper.txt
==============================================================================
--- pypy/trunk/doc/oscon2003-paper.txt (original)
+++ pypy/trunk/doc/oscon2003-paper.txt Sun Jul 6 23:35:43 2003
@@ -1,8 +1,8 @@
-==============================
Implementing Python in Python
==============================
+
A report from the PyPy project
-------------------------------
+******************************
The PyPy_ [#]_ project aims at producing a simple runtime-system for
the Python_ language, written in Python_ itself. **C** and **Lisp**
@@ -31,10 +31,7 @@
Eventually, we would like to produce a faster Python_ , which should
please all. We are very far from that now, because speed is a distant
goal. So far we have only worked on making PyPy_ *simple* and
-*flexible*.
-
-How have we set about it
-------------------------
+*flexible*.
Most of you know what happens if you type::
@@ -53,12 +50,13 @@
This raises an interesting question. What would *doing more of those*
mean? The PyPy_ project takes one approach.
-Background
-----------
+Terminology
+***********
In a Python-like language, a running interpreter has three main parts:
+
* the main loop, which suffles data around and calls the operations defined in the object library according to the bytecode.
- * the compiler, which represents the static optimization of the source code into an intermediate format, the bytecode;
+ * the compiler, which represents the static optimization of the source code into an intermediate format, the bytecode; and
* the object library, implementing the various types of objects and their semantics;
In PyPy, the three parts are clearly separated and can be replaced
@@ -73,32 +71,73 @@
We call the separable object library, an *Object Space*.
We call *Wrapped Objects* the black boxes of an Object Space.
-But the exciting thing is that while existing languages implement _one_
+One exciting thing is that while existing languages implement _one_
Object Space, by separating things we have produced an architecture
which will enable us to run more than one Object Space in the same
-interpreter at the same time. This idea has some exciting implications.
+interpreter at the same time. This idea has some interesting implications.
+
+But first let us dream for a bit. (Aside from having fun, why should
+we spend our time writing PyPy?
+
+Goals:
+++++++
+or Dreams, if you prefer
+
+A Slimmer Python
+****************
+
+People who write code for handhelds and other embedded devices often wish
+that they could have a much smaller footprint. Now they can ask for a
+Tiny Object Space which only implements the behaviour which they need,
+and skips the parts that they do not.
+
+A Smarter, more Dynamic Interpreter
+***********************************
+
+There is no reason why your Python_ interpreter could not keep statistics
+of how it is being used, and automatically select from a collection of
+algorithms the one which is best suited for the data at hand.
-So let us dream for a bit.
+Multiple, Dynamically changing Implementations of a single type
+***************************************************************
-First dream: How do you get computer science concepts in language design more effectively into student brains?
-**************************************************************************************************************
-Traditionally, academics come up with interesting new ideas and
-concepts, but, to the extent that they are truly new end up creating
-another language to express these ideas in. Unfortunately, many
-languages end up merely as a vehicle for too few new ideas. We end up
-force-feeding our poor students with too many computer languages, too
-quickly -- each language designed to teach a particular point. And
-many of our languages are particularly weak on everything _but_ the
-point we wish to make.
+Consider the question: *What is the best way to implement a dict*?
+
+The answer depends on how much data you intend to store in your dict.
+If you never expect your dict to have more than a half dozen items, a
+really fast list may be best. Larger dicts might best be implemented
+as hashes. And for storing enormous amounts of data, a binary tree
+might be just what you desire. In principle, there is
+nothing to stop your interpreter from keeping statistics on how it is
+being used, and to move from strategy to strategy at runtime. You
+could implement this in CPython, but we intend to make it a lot
+*easier* to do this in PyPy_ to encourage such experimentation.
+
+A better teaching vehicle
+*************************
+Academic computer science is littered with tiny teaching languages.
+Every time we get a few new ideas in language design or pedagogical
+theory we itch to create a language to express these ideas. While
+understandable, this is wasteful. Many languages are implemented which
+are more novel than useful, and too many are begun with insufficient
+new ideas. We end up force-feeding our poor students with too many
+computer languages, too quickly -- each language designed to teach a
+particular point. And many of our languages are particularly weak on
+everything *except* the point we wish to make.
+
+In reaction, many students desire to only learn **commercially
+successful** languages. While they avoid trivial languages, some of them
+avoid learning Computer Science altogether. They learn how to program,
+but that is about it. There has got to be a better way.
Things would go a lot more smoothly if we could only create an Object
-Space which obeys the new rules we have thought up, and drop it into
-an existing language. Comparisons between other ways of doing things
-would also be a lot simpler. Finally, we could reasonably ask our
-students to implement these ideas in Python_ and let them drop them in,
-leaving all the other bits, irrelevant for our educational purposes as
-they already are written. There is no better way to learn about
-compiler writing, than writing compilers, but a lot of todays
+Space which obeys the new rules we have thought up, and drop it into a
+successful existing language. Comparisons between other ways of doing
+things would also be a lot simpler. Finally, we could reasonably ask
+our students to **implement** these ideas in Python_ modifying the
+interpreter but leaving all the other bits, irrelevant for our educational
+purposes as they already are. There is no better way to learn
+about compiler writing, than writing compilers, but a lot of todays
education in compiler writing leaves a huge gap between 'the theory
that is in the book which the student is expected to learn' and 'what
is reasonable for a student to implement as coursework'. Students can
@@ -110,24 +149,8 @@
Object Spaces will provide a better fit between the the abstract
concepts we wish to teach and the code written to implement just that.
-Dream number Two: A Slimmer Python
-**********************************
-
-People who write code for handhelds and other embedded devices often wish
-that they could have a much smaller footprint. Now they can ask for a
-Tiny Object Space which only implements the behaviour which they need,
-and skips the parts that they do not.
-Dream number Three -- Multiple, Dynamically changing Implementations of a single type
-*************************************************************************************
-This depends on how much data you intend to store in your dict. If you
-never expect your dict to have more than a half dozen items, a really
-fast list may be best. Larger dicts might best be implemented as
-hashes. And for storing enormous amounts of data, a binary tree
-might be just what you would be interested in. In principel, there is
-nothing to stop your interpreter from keeping statistics on how it is
-being used, and to move from strategy to strategy at runtime.
Dream number Four -- You might want to change how operators work, as well
*************************************************************************
@@ -156,12 +179,6 @@
that the computation was too strenuous for such a device, and automatically
forward the computation to a machine with more computational power.
-Dream number Seven -- A Smarter, more Dynamic Interpreter
-*********************************************************
-
-There is no reason why your Python_ interpreter could not keep statistics
-of how it is being used, and automatically select from a collection of
-algorithms the one which is best suited for the data at hand.
Dream number Eight -- How to avoid painful conversion of your code base to new versions of the language.
********************************************************************************************************
@@ -263,7 +280,7 @@
an artificial goal. Specifically, it calculated the share in foodbill
for each of the 9 Sprint participants.
::
-### the first use of PyPy as a tool to do something else ###
+### the first use of PyPy as a tool to do something else ### [#]_
slips=[(1, 'Kals MatMarkn', 6150, 'Chutney for Curry', 'dinner Saturday'),
(2, 'Kals MatMarkn', 32000, 'Spaghetti, Beer', 'dinner Monday'),
@@ -474,7 +491,7 @@
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
- Although never is often better than **right** now.
+ Although never is often better than _right_ now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!*
More information about the Pypy-commit
mailing list