You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the compiler has finished support for the WebAssembly target, we should reimplement the interpreter functionality on top of it. There are a few major reasons for this:
The runtime support needed by the current interpreter differs significantly from that needed by the code generated by the compiler; and that gap will only grow over time.
The feature set supported by the interpreter and compiler will differ, and since most resources are focused on the compiler, the interpreter will fall behind. If the interpreter builds on top of the compiler, then they remain at parity with each other, and provides a straightforward way to expose a Lumen playground on the web.
As the compiler improves, we will be able to move more and more code out of Rust, and into Erlang source, moving to a semi-bootstrapped, or even fully bootstrapped model down the road. This gets complicated if we have to maintain the current interpreter, since it necessarily requires the Rust APIs. Ideally, we'd eventually move the interpreter into an entirely dynamic Erlang implementation, which would end up much simpler, and would act as the foundation for a REPL.
NOTE: This is a long-term goal, not an immediate focus. That said, we should keep in mind that this is where we want to go, and try and incrementally work towards it as much as we can. If we find that we can't continue to support the interpreter, it would be better to remove it and build the new implementation when we're able, rather than keep it around, due to the burden it imposes. That would necessarily require the compiler to be fully functional, but we're already pretty close to that stage now.
The text was updated successfully, but these errors were encountered:
When the compiler has finished support for the WebAssembly target, we should reimplement the interpreter functionality on top of it. There are a few major reasons for this:
NOTE: This is a long-term goal, not an immediate focus. That said, we should keep in mind that this is where we want to go, and try and incrementally work towards it as much as we can. If we find that we can't continue to support the interpreter, it would be better to remove it and build the new implementation when we're able, rather than keep it around, due to the burden it imposes. That would necessarily require the compiler to be fully functional, but we're already pretty close to that stage now.
The text was updated successfully, but these errors were encountered: