
Show HN: Lua/LuaJIT with C/C++/Java/JavaScript syntax - mingodad
https://github.com/mingodad/ljs
======
coder543
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.

------
mingodad
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](https://github.com/mingodad/ljs/tree/master/lua2ljs)
.

Here are some non trivial projects converted to LJS:

ljsjit at
[https://github.com/mingodad/ljsjit](https://github.com/mingodad/ljsjit)

ljs-5.1 at
[https://github.com/mingodad/ljs-5.1](https://github.com/mingodad/ljs-5.1)

ZeroBraneStudio port at
[https://github.com/mingodad/ZeroBraneStudioLJS](https://github.com/mingodad/ZeroBraneStudioLJS)

raptorjit-ljs at [https://github.com/mingodad/raptorjit-
ljs](https://github.com/mingodad/raptorjit-ljs)

snabb-ljs at [https://github.com/mingodad/snabb-
ljs](https://github.com/mingodad/snabb-ljs)

premake5-ljs at [https://github.com/mingodad/premake-
core/tree/ljs](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/](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.

~~~
dividuum
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?

~~~
mingodad
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.

------
sifoobar
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](https://gitlab.com/sifoo/snigl#tracing)

~~~
mingodad
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 !

~~~
sifoobar
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.

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

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

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

