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.
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.
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.
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?
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.
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.
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.
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.
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.
30 comments
[ 2.8 ms ] story [ 77.4 ms ] threadAlso 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.
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
https://news.ycombinator.com/item?id=9981802
https://news.ycombinator.com/item?id=10078848
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.
Cheers !
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?
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
Best wishes !
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!
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.
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.