Hacker News Reader

Comment by DanWaterworth | Hacker News Reader

If you look at the TODO list, it looks like they want to replicate PyPy's approach. I wonder, have they considered writing an rjavascript to rpython compiler and just using the pypy infrastructure as is?

View on HN

I had considered this, but it would also require the other end of it. RPython is basically compiled to C which is compiled to machine code. The ultimate output format for this needs to be JavaScript, something like the form specified by https://github.com/dherman/asm.js. So we need JavaScript (ES6) coming in one end and asm.js coming out the other end. At this point the only remaining usable pieces from PyPy are the processing that happens in the middle. Admittedly this is a huge part of it and would still be very valuable to have access to, but there's probably a better approach to this than having to redo both ends of the pipeline, and losing the ability to self-host the compilation process in a JavaScript engine (browser).

Perhaps pairing PyPy with emscripten would be the ideal solution for this, but that would have to be a completely new project because nothing that's currently in Continuum would be useful for that (except probably the standard library that's written in ES6 and executed in the VM).

OK, I understand. I was under the impression that the purpose of the meta-interpreter was to create a virtual machine outside of the browser, but having re-read your README, I now understand this isn't the case.

Still, I would recommend trying to reuse PyPy's infrastructure, even if only for the short term. An immense amount of time and thought has gone into creating it that you would end up replicating otherwise.

Besides, PyPy doesn't just target C, it also target's JVM and .Net, so in writing a new backend for JS, you wouldn't be working against the grain.

There's no need to have a restricted Javascript. All you have to do is to write code in ES6 with the type annotations and the entire program will be fully type-inferable (tho the inferring part may take a while because you probably need to do something like a Cartesian product for duck typing). Once you do that, you can do a lot of optimizations.

You need to do things like not dispatch to valueOf and toString for coercion. You basically just need to get rid of dynamic coercion dispatch, and do what you said (annotate types) and that's all that's really needed. But the ECMAScript runtime is pretty substantial so having a minimized subset of that runtime would make it possible to self-host most of the higher level interpreter in ES6-like code instead of having most of it implemented in ES3 (as it is now). This makes a significant difference in verbosity of the code. As converted to ES6, I estimate the code would be half of what it is now (currently it contains ~23k lines of ES3 code, 7k lines of ES6 code, so 30k total).

Actually, you need to not use a few more features too, like not dynamically attaching properties to objects at run time, and dynamically creating new clasess... but the point is, you don't need to define a new language when all you have to do is to use only a subset.

Well RPython is just that: a restricted subset of Python (hence the name). Similarly, asm.js is a (small) subset of ECMAScript targeted at compile-to-js code generators. It's just about specifying what the subset contains, not inventing a new language.

Reply on news.ycombinator.com