Check out cool esmeta project
Closed this issue · 3 comments
https://github.com/es-meta/esmeta . This is Scala program, which parses ecmascript spec and... converts it into actual interpreter!
See here oxc-project/oxc#4439 for details, in particular, why I think esmeta is useful for Nova.
(This is not a bug, just an idea.)
In other words, it is an ECMAScript interpreter that builds its specification abstract operations semi-automatically from the spec text itself.
So what you're saying is, it would be a good idea to build an interpreter by using an interpreter? I see a few problems with this.
- Nova would have to include Scala and the JVM to run esmeta.
- Running the abstract operations using an interpreter leads to them being interpreted code instead of natively compiled functions with possible fast paths injected for common cases. The interpreter, ie. the engine, necessarily runs a lot slower by doing this.
- You mention in the linked ticket that esmeta solves the "issue" of:
We could go and try to refactor Object inheritance in eg. V8, or Kiesel, or LibJS. But it's most likely that this would never be accepted
I don't see how esmeta solves the "issue" that internal implementations of Objects in certain engines being built in a way that does not match what I'm trying to achieve in Nova. They do not use esmeta to build their engines, so esmeta doesn't change those engine's internal implementations.
Now, if we were using esmeta then we could change the spec and the esmeta-generated interpreter would change. But I find it even more doubtful that the spec would be changed to match my ideas. So the only option we'd be left with would be to maintain our own fork of the spec where we encode the changes. But we'd still be left with problems 1 and 2.
And what would we be left is that we are an engine that does not implement an engine at all, but instead runs someone else's engine.
Would you suggest V8 and JavaScriptCore do the same?
First of all: this is just idea. I just suggested taking some parts or ideas from ESMeta project. If you don't like this idea, this is okay.
In other words, it is an ECMAScript interpreter that builds its specification abstract operations semi-automatically from the spec text itself.
Yes
Nova would have to include Scala and the JVM to run ESMeta
It is possible to write something similar to ESMeta in Rust. It is easier than writing full-featured js engine from scratch manually.
necessarily runs a lot slower by doing this
You can modify ESMeta (or implement your own replacement), which generates Rust instead of IRES (I described here oxc-project/oxc#4439 , what is IRES). Rust is compiled language, so, we will get single level of interpretation, not two. So, resulting js engine will be fast enough. But not super-fast, either, because it will not be optimized. We will get easy-to-understand and easy-to-modify Rust code, which will resemble spec itself. It is probably even possible to generate Rust (instead of IRES) with data-oriented design. And I think all this is easier to implement than full-featured js engine.
So the only option we'd be left with would be to maintain our own fork of the spec where we encode the changes
Yes, this is what I meant.
Would you suggest V8 and JavaScriptCore do the same?
Of course, no, because they are engines fighting for maximal speed. If you want maximal speed, too, then, of course, basing nova on ESMeta is bad idea. But if you just want to be "fast enough", then ESMeta, which generates Rust instead of IRES, will probably go.
And in any case ESMeta is good as an engine to compare nova to. I. e. you can make necessary changes to spec, generate matching js interpreter from it using ESMeta, and then make changes to nova until nova behaviour matches ESMeta behavior.
And again, all these is not necessary. I just want to share interesting project
First, thank you for taking the time to actually write out what sort of possibilities you see and why someone (Nova in this case) should care or look at your idea. In the future I suggest leading with a more fully thought out and thoroughly written message. One sentence with a link leading to another vague lone sentence gives the appearance that you have little idea of what you're talking about. In short, at least I think it's quite rude.
Or if you don't want to write out your ideas and just want to boost an interesting project then I suggest doing it in social medias. Our Discord would be a great place to have sent the original message.
It is possible to write something similar to ESMeta in Rust. It is easier than writing full-featured js engine from scratch manually.
I would expect you're underestimating the complexity of creating ESMeta. Still, this is a possible avenue.
You can modify ESMeta (or implement your own replacement), which generates Rust instead of IRES (I described here oxc-project/oxc#4439 , what is IRES). Rust is compiled language, so, we will get single level of interpretation, not two. So, resulting js engine will be fast enough. But not super-fast, either, because it will not be optimized. We will get easy-to-understand and easy-to-modify Rust code, which will resemble spec itself. It is probably even possible to generate Rust (instead of IRES) with data-oriented design. And I think all this is easier to implement than full-featured js engine.
I expect that it would be somewhat more complex than we'd expect to produce valid Rust from the specification. I expect the difference between producing an "interpretation" of calling an abstract operation versus producing a callable function from it might be different things. But this is an interesting proposal and I highly recommend you look into this.
And in any case ESMeta is good as an engine to compare nova to. I. e. you can make necessary changes to spec, generate matching js interpreter from it using ESMeta, and then make changes to nova until nova behaviour matches ESMeta behavior.
There is something potentially interesting hereabouts. If you could produce inlined IRES of certain calls (eg. accessing indexes) and then add on restrictions (accessed object is Array) to see what restrictions allow you to drop what checks, then this could serve as a fast-path generator. Or conversely, generate the inlined IRES and analyse it for check paths and what enables you to skip them.
This would be a potentially useful semi-JIT.
That being said, I am not at this moment interested in exploring automatic translation of spec text into Rust, or building a proof engine / optimising compiler on IRES. I will thus close this issue, but I recommend you take your ideas and try building something out of them. It might turn out very well.