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 motivation. A bientot, Armin.

Hi Seo, On Wed, May 03, 2006 at 09:32 +0900, Sanghyeon Seo wrote:

2006/5/3, Armin Rigo <arigo@tunes.org>:

...

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.

Sadly, parsing Javascript is unnecessarily difficult because of optional semicolon insertion. Best to look at existing parsers.

IMO for a SoC project it would be ok to have a stricter parser. Having javascript programs running on top of PyPy (JsPy or whatever :) being able to run unmodified on other javascript interpreters would be interesting enough. And such an approach would still have the advantages that Armin points out. best, holger