[pypy-dev] Google summer of code is open student for submissions

Armin Rigo arigo at tunes.org
Wed May 3 00:40:19 CEST 2006

Hi Fabien,

On Tue, May 02, 2006 at 11:57:10AM +0200, Fabien Schwob wrote:
> And I would like to have more information about it if possible. I would
> like to check if I understand it. So the goal would be to parse the
> Javascript instructions and to create an AST tree from it ? So, it would
> be possible to write Javascript code that can be after executed on the
> PyPy backends (CLI, C, LLVM, etc...).

The goal is to write an *interpreter*.  At this point it's completely
unrelated to the translation backends.

Let's consider Javascript (the same argument applies to any interpreted
language): to write an interpreter, some people focus on the task of
compiling, say, Javascript source code to get an AST; this is only part
of the job, and it should be the shortest part -- ideally, finding an
existing parser would be best, otherwise plugging one together with
existing tools shouldn't take too long for a regular language like
Javascript.  It could be an AST or bytecode in any format.  The core of
the work is actually to build an interpreter for this AST or bytecode,
because in addition to the AST or bytecode interpreter you also need to
put together the object model, and build the standard types.  This means
basically rewriting a Standard Interpreter that interprets Javascript
instead of full Python -- for what Standard Interpreter exactly means
here, see http://codespeak.net/pypy/dist/pypy/doc/architecture.html .
(Getting the basics working to interpret Javascript is rather easier
than to interpret Python, as the JS language and object model are far
simpler; nevertheless, a two-months job will probably leave many details
unpolished, which is ok.)

Per se, this goal is not related to the back-ends of the Translation
Process of PyPy (see again the same link for "Translation Process").  So
it's not about providing either a front-end nor a back-end for
Javascript.  The reason it's still interesting to write a JS interpreter
is that the JS interpreter itself can then be turned into C code, or
.NET code, or any of the platforms that the Translation Process supports
or will support.  In this way, writing a JS interpreter onces gives you
Javascript.NET, Javascript-on-Java, etc. all at once, using the
unmodified translation toolchain.  This works for any program written in
the PyPy framework (i.e. written in RPython); but the reason PyPy is
well suited to write - more specifically - *interpreters* instead of
something else, is about what interesting things we can do with the
RPython program if it's an interpreter.  This means e.g. turn it into a
Just-In-Time compiler.  Our goal (not achieved yet) is that with
relatively little efforts, each of the interpreters written in the PyPy
framework will be turned into JIT compilers.  So we might later obtain a
Javascript JIT out of the Summer of Code-sized Javascript interpreter
:-)  Clearly, that's outside the scope of the project, that's just

A bientot,


More information about the Pypy-dev mailing list