Saying C/C++/Java/JavaScript makes me think you've created 4 different syntax frontends for LuaJIT, when there is really only one here.

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.

Also if you have done any enhancement to Lua/LuaJIT and want help or talk about it I'm glad to hear from you.

There is an parser/transpiler using lemon/re2c that can transpile almost any Lua source to LJS see here https://github.com/mingodad/ljs/tree/master/lua2ljs .

Here are some non trivial projects converted to LJS:

ljsjit at https://github.com/mingodad/ljsjit

ljs-5.1 at https://github.com/mingodad/ljs-5.1

ZeroBraneStudio port at https://github.com/mingodad/ZeroBraneStudioLJS

raptorjit-ljs at https://github.com/mingodad/raptorjit-ljs

snabb-ljs at https://github.com/mingodad/snabb-ljs

premake5-ljs at https://github.com/mingodad/premake-core/tree/ljs

The next steps that I have in mind now is to add the remaining syntax sugar like:

-C/C++/Java/Javascript for loop

-Switch statement

-Class statement

-const declarations

- type checking (actually https://fascinatedbox.github.io/lily/ has those and it seems a good one to port/add)

-Understand and make it easier for other people understand the implementation of LuaJIT.

I only poked into the source code on github a bit, so I might be entirely wrong, but from what I understand, the original Lua runtimes (stock Lua, Luajit, etc) were modified for a new syntax? If so, what's the motivation for this approach? Since you already have an lua2ljs transpiler, wouldn't it be easier to use this knowledge to instead have an ljs2lua transpiler and just reuse all existing Lua implementations? Similar to how moonscript works?

Fair point but I prefer less code to mantain move around, as you pointed out it's only a moderate modification of the Lua lexer/parser and not need anything else ~200KB ljs, ~500KB LjsJIT interperter and there you go.

For some reason, it reminds me of Squirrel language[1] and Lemon language[2].

  [1] http://www.squirrel-lang.org/
  [2] http://www.lemon-lang.org/

I'm also forked the Squirrel at https://github.com/mingodad/squilu fixing some in my point of view missing features and making it accept a small subset of C/C++ language.

Maybe also properly separated list/array, map/dict and set types? The I-am-everything-{} type in lua is a bit unergonomic when you want to use it as only such a type and a stumbling block for unfamiliar users.

Can a project using 5.3 lua continue using existing .lua files but also write new files in .ljs?

> switch

Aren't match statements all the rage nowadays? Even C++20 get's one (with a silly name, of course)!

> class

Finally, setmetatable is nice, but, yes, "proper" not handrolled classes.

> const

Too few scripting languages have these. Do you intend to make this include interior mutability as well or is this only pointer deep?

The general idea is to be able to reuse code as much as possible, and C/C++/Java/Javascript style syntax make a lot of code available and if we ditch the 1 based index in favor of 0 based it makes it even easier.

It looks like it's still 1-based currently, is that right? 1-based arrays have been the biggest obstacle to me using Lua.

I did years of assembly, then C, and now Lua. I've yet to find the 1-based indexing to be an issue, and that's even having written a few C modules to manipulate Lua arrays. What is it about the 1-based arrays that is so off-putting?

Again the point is easy code reuse.

Yes you are right it's still 1 based to allow easy conversion from actual existing Lua projects.

FYI, the link for https://github.com/mingodad/raptorjit-ljs is down.

Congrats for the project, transpilers are great fun.

An impactful project and a logical next step would be writing a new version of Moonshine (http://moonshinejs.org/) or writing a modern full-blown Lua to JS transpiler.

Thank you for pointing it out. Fixed.

Cheers !

Who maintains LuaJIT these days?

Good question !

It seems that Mike Paul is still the main one that do it.

Now there is a repository on https://github.com/LuaJIT/LuaJIT/issues and after send a message to the mailing list and no answer for few days another user told me about it and I opened an issue of a problem I found while converting LuaJIT to LjsJIT see https://github.com/LuaJIT/LuaJIT/issues/461

Also, CloudFlare was "stewarding" the project (not sure what it exactly means) but they seem to be moving away their codebase away from Lua.

There’s also an active fork of LuaJIT called RaptorJIT that’s oriented towards building whole applications rather than embedding.

Interesting do you have any references about this?

These are a few years old:

https://news.ycombinator.com/item?id=9981802

https://news.ycombinator.com/item?id=10078848

They had a blog post about LuaJIT profiling just a couple of weeks ago https://blog.cloudflare.com/more-consistent-luajit-performan...

Have you considered a limited form of typescript transpilation?

Yes that's a nice goal and in order to have it we need "class/switch/enum/...", come onboard and help implement then.

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.

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.

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.

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.

[0] https://gitlab.com/sifoo/snigl#tracing

Hello Andreas ! It's an interesting approach for jit, I did looked at your link and one of the reasons to reshape Lua with a C/C++/Java/Javascript syntax was code reuse and learning curve, at first looking at the syntax of snigl it seems that you'll need to rewrite a lot of software to make the language usable and convince people that the learning curve and small comunity will be worth at the end.

Best wishes !

Just noting that JIT means speculating from what you've seen so far, what I'm doing is proving invariants and removing redundancy at compile time. Which means more predictable performance, since the code stays the same once it starts running; and a less complex implementation, since there's no need to de-optimize anything.

The reason I'm tracing is that it's the only way I've found to prove anything of value in such a formless language; even Lisp knows which arguments belong to which function call, in Forth that depends on what came before.

And it fits well with an interpreted language, since a slow compile often defeats the purpose of compiling in the first place. The tracing I've implemented so far is instant in comparison.

Agreed; C, Forth & Lisp are all acquired tastes. Which is fine, one size never fits all.

Just wanted to mention some alternatives to LuaJIT, since I don't think it's a viable way forward for languages of this scale.

Likewise!

Thanks for sharing this.This is what I want use for embedded in C projects,the same syntax.

This looks like JS, and JS does not look like C/C++/Java

I suspect OP is referring to things like the braces, do/while, etc, that are common to all of those, and not in Lua.