Saying C/C++/Java/JavaScript makes me think you've created 4 different syntax frontends for LuaJIT, when there is really only one here.<p>It seems to me that you're really trying to express a concept that could be referred to as "C-like syntax" or "JavaScript-like syntax," with the latter probably being more accurate. It would certainly be less confusing than repeating "C/C++/Java/JavaScript syntax" over and over.
Author here if you have any question.<p>Also if you have done any enhancement to Lua/LuaJIT and want help or talk about it I'm glad to hear from you.<p>There is an parser/transpiler using lemon/re2c that can transpile almost any Lua source to LJS see here <a href="https://github.com/mingodad/ljs/tree/master/lua2ljs" rel="nofollow">https://github.com/mingodad/ljs/tree/master/lua2ljs</a> .<p>Here are some non trivial projects converted to LJS:<p>ljsjit at <a href="https://github.com/mingodad/ljsjit" rel="nofollow">https://github.com/mingodad/ljsjit</a><p>ljs-5.1 at <a href="https://github.com/mingodad/ljs-5.1" rel="nofollow">https://github.com/mingodad/ljs-5.1</a><p>ZeroBraneStudio port at <a href="https://github.com/mingodad/ZeroBraneStudioLJS" rel="nofollow">https://github.com/mingodad/ZeroBraneStudioLJS</a><p>raptorjit-ljs at <a href="https://github.com/mingodad/raptorjit-ljs" rel="nofollow">https://github.com/mingodad/raptorjit-ljs</a><p>snabb-ljs at <a href="https://github.com/mingodad/snabb-ljs" rel="nofollow">https://github.com/mingodad/snabb-ljs</a><p>premake5-ljs at <a href="https://github.com/mingodad/premake-core/tree/ljs" rel="nofollow">https://github.com/mingodad/premake-core/tree/ljs</a><p>The next steps that I have in mind now is to add the remaining syntax sugar like:<p>-C/C++/Java/Javascript for loop<p>-Switch statement<p>-Class statement<p>-const declarations<p>- type checking (actually <a href="https://fascinatedbox.github.io/lily/" rel="nofollow">https://fascinatedbox.github.io/lily/</a> has those and it seems a good one to port/add)<p>-Understand and make it easier for other people understand the implementation of LuaJIT.
I like a lot of things about Lua, the focus on embedded use and keeping the implementation nimble among others. LuaJIT is very impressive, but it's already drowning in its own complexity.<p>I spent the last two years more or less full time trying out ways of making interpreters of similar complexity go faster without making the same mistake.<p>One method that seems really promising so far is AOT tracing [0], making guarantees and removing redundant code ahead of time based on incomplete semantic models. It's different from a full compiler in that it only tries to improve the situation and will back out and leave code alone where the semantic model is insufficient. And since it acts as a transformation on VM code, it's fairly transparent and easy to debug. The complexity of the models is a three way compromise between faster tracing, faster code and implementation complexity.<p>Once the VM code is reasonably optimal, further compiling to C by generating the interpreter code inline becomes even more attractive. Which also leads to native executables as a bonus feature.<p>[0] <a href="https://gitlab.com/sifoo/snigl#tracing" rel="nofollow">https://gitlab.com/sifoo/snigl#tracing</a>