[pypy-dev] Summer of PyPy pre-proposal

Armin Rigo arigo at tunes.org
Sat Aug 12 10:45:31 CEST 2006


Hi Leonardo,

On Fri, Aug 11, 2006 at 06:59:00PM -0300, Leonardo Santagada wrote:
> I would like to enter Summer of Pypy with my proposal to make a
> javascript interpreter. I had a chat with some nice people in #pypy
> and they thought it was a good idea.

Nice plan :-)

> So I checked the code and started
> looking at what should/can do on 2 months of work ( I don't know if
> there is this limitation on time).

Not necessarily, but the proposal should have a timeline and your
calendar should allow you to put "reasonable" amounts of work on it.

> I am a litle lost with all the code
> from pypy and the idea of making another interpreter so I am posting
> here my ideas and I am specting your feedback.
> 
> What do you think I need to do? define a javascript virtual machine or
> do simple direct interpretation of the source?

I'm not completely clear about the difference between a simple direct
interpreter and a virtual machine.  JavaScript like Python is a language
where the main work is in getting the execution model and the object
model right.  For the object model I mean building the Python classes
that support the various kinds of JavaScript objects -- "kind" as in the
[[Class]] internal property -- with all the other internal properties
and methods; and then making the pre-built objects and prototypes and
functions.  It's ok to leave out some parts of the library of pre-built
objects for the Summer of PyPy's duration.  (This part corresponds to
PyPy's "object spaces".)

For the execution model, as you note, you need to start with an
interpreter.  It would interpret bytecodes that you are free to invent;
I guess they would directly correspond to JavaScript syntax elements.
(What I mean by execution model also includes things like function and
method calls, and how to fit built-in functions.)  (This part is
documented under the name "bytecode interpreter" in PyPy.)

(JavaScript ref.:
http://www.ecma-international.org/publications/standards/Ecma-262.htm)

> Should I use the parser defined on pyparsing (this one seems really
> nice) or write one manually?

I'm not sure about this.  Our tokenizer and parser are definitely meant
to be reusable, but I'm not exactly sure how :-/  I think there is a way
to recompile the tables in pytokenize.py.  The parser loads a grammar
dynamically, so that's simpler.  My 2 cents, though, is that you don't
start the work here; if you know about another JavaScript parser that
produces some data that is easy to feed to Python, it would be a good
start.  (Ultimately, we really need a parser written in RPython, but
it's ok to leave this out of the Summer of PyPy proposal.)


A bientot,

Armin



More information about the Pypy-dev mailing list