A comment <https://github.com/LuaJIT/LuaJIT/issues/1475#issuecomment-47...> has already been made on the issue regarding the ternary operator, recommending `if x then y else z` over `x ? y : z`. This is exactly how it's done with if-then-else expressions in Luau <https://luau.org/syntax/#if-then-else-expressions>, another language compatible with Lua, and makes it a ton easier to nest (especially with elseif) and I believe still easier to read than `y if x else z`.

So is LuaJIT resuming active development after a decade or so of only maintenance? Great!

A lot of these changes make sense (although some of them are a bit too TIMTOWTDI for my taste) - but perhaps LuaJIT 3 would benefit from a change of name as well? Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.

Lua 5.3 (2015-01-12) added the bitwise operators:

https://www.lua.org/versions.html#5.3

https://www.lua.org/manual/5.3/manual.html#3.4.2

Looks like LuaJIT is catching up, but calling these "syntax extensions" is confusing. Is the intent to hold LuaJIT fixed against some earlier Lua version (I guess 5.1) and adopt newer syntax piecemeal?

I welcome the compound assignment operators. Playdate's version of Lua also has that extension.

> For compatibility with other computer languages, the following classic Lua operators can be written in a more customary syntax:

Why though? What does changing `and` to `&&` actually achieve? Were people confused?

Changing the syntax seems very surface level. It's not actually fixing any problems, just making Lua no longer look like Lua. It's not going to help anyone write/learn Lua. It will make everything more complicated as there are now two ways to do everything.

This feels like adding braces to Python because you don't like indenting your code.

Tangently related but I’ve been deep in Lua recently working on a rust implementation that supports Lua 5.1-5.5 in one Rust Binary https://github.com/ianm199/omnilua.

My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.

One of the interesting things about Lua is because they don't really maintain compatibility between major versions, there isn't a huge ecosystem, and as a result there's less friction against making your own, slightly incompatible version. When you add on the simplicity of implementing the language, it's created a really diverse set of lua-alikes. Weird (and cool) for a language to have a diverse ecosystem of implementations, but not necessarily libraries.

I see JavaScript.

Some of these really look like QoL improvements. I'm not convinced ternary statements are an ergonomic improvement in particular. The examples given don't make a compelling case, 'visually tidy' is not the same as readable.

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

It might have been better to publicly document and stabilise the LuaJIT bytecode, which would allow people to then come up with whatever syntax they wanted in their own custom frontends.

For others interested in alternative syntax to the Lua VM/API sometime ago I've created LJS https://github.com/mingodad/ljs and also https://github.com/mingodad/ljsjit, I've also included an utility lua2ljs program based on the Lemon parser and re2c that convert Lua scripts to LJS with line by line synchronization https://github.com/mingodad/ljs/tree/master/lua2ljs, to test it I've also translated a few non trivial projects (https://github.com/mingodad/ZeroBraneStudioLJS , https://github.com/mingodad/raptorjit-ljs, https://github.com/mingodad/snabb-ljs, https://github.com/mingodad/premake-core/tree/ljs, https://github.com/mingodad/CorsixTH-ljs).

I'm proud of it and thankfull to the Lua/Luajit projects.

Looks like LuaJIT is really going to fork away from Lua this time. After these changes, it won't be a compatible Lua 5.1 implementation anymore, it will be a new language.

So shouldn't it have a new name?

LuaJIT has held back the lua ecosystem for over a decade. There's no reason to not at least try to move the implementation closer to luau or puc lua, not create yet more incompatible syntax

The syntax proposals look fine. But I don’t feel they are needed. Lua is easy to write and grok. I default to using LuaJIT, and have never had an issue with the actual code. Integration with the Lua ecosystem is the problem. Fix the compatibility issues with LuaRocks packages and PucRio. That would be the best dev ex update in my opinion.

+= and ..= are things i find i'm constantly missing in lua.

Personally im a fan of introducing ternaranary operator in lua. Everyone uses `x and y or z` as a ternanary which i find way more confusing than ?:

They shouldn't add the ternary operator, it keeps `?` from being usable on it's own for safe navigation and requires the ugly `?.` operator, like `a?.[b]` or `f?.()` instead of `a?[b]` or `f?()`.

Seems like a bad idea to actively diverge from Lua, hostile even, especially without at least a clear change of name.

I thought luajit had completely stopped feature updates

I’m confused I thought Mike Pall left luajit and Laurence Tratt took over as maintainer?

Some of these things are already implemented in PUC Lua. I don't know why they are diverting from lua spec on other aspects though. Why not work together with the PUC Lua team to add some of these to both lua versions and work on bringing their functionality closer to each other instead of further apart. You might as well just make a new language instead. New features will end up not being used in effort to keep lua scripts portable.

In effort to not pollute the github issue, and hopes that the authors read this thread, I will put some of my thoughts here. There are 3 main strengths of Lua: Embeddable, Fast, and Small(easy to learn). I worry some of these changes divert from the last, expanding the language into a more complicated language.

Here is a list of things already implemented in PUC Lua so can be considered safe to add:

  ● ~ a     Bitwise negate
  ● a & b   Bitwise and
  ● a | b   Bitwise or
  ● a ~ b   Bitwise Xor
  ● a << b  Left-shift
  ● a >> b  Logical right-shift
  ● a // b  Floor divide
  ● break   Break statement

  ● Const keyword: changing const from `local a <const> = 42` to `const a = 42` is far better syntax. The bracketed syntax was never a good idea.
  ● nil-Coalescing and safe navigation are great additions as they are basically macros at the parsing stage.
  ● Compound assignment is also basically a macro at the parsing stage as well. Lua should already have this honestly.
  ● Ternary Operator: I *like* it and it will help the stumbling block of the `a and b or c` common pattern already in use. Though I think (like others have stated) the If/then/else syntax would be more inline with the language, similar to ruby and would enable far more emergent behaviour. However it does establish a new pattern that the last value in a block is a return value similar to ruby so I am conflicted about that.
  ● `continue` it is nicer than a goto and is helpful.
  ● String interpolation: I honestly don't love lua's concat operator `..` so honestly string interpolation would be a nice to have and a feature of many modern languages. However I do worry about it's effect on parsing performance, and complexity of the language.
  ● Underscores in numbers: *shrug*

  ● The `and` `&&` and `or` `||`. This just goes in the wrong direction for lua. It is often confusing in ruby (especially because of precedence issues) but also lua is a wordy language. It has `do` `end` blocks instead of brackets. It adds ambiguity for no reason.
  ● Short form function syntax. Lua does not need this and I am not sure anyone asked for this. Why `a = |x| do ... end` is more helpful than just `a = function(x) ... end` is unclear and would love to hear more about why this is being considered.
  ● Named varargs: It may be nice, but there is no real reason to add this. If you wanted a name for your varargs you could do `local name = ...` or just use the `args` variable already available in every function.
  ● Switch/Match/Select Statements: An optimized if/else block works just as well and another expansion of a small language.

I would love to see all of these come to LuaJIT (and love2d to support the new version too). It’s nice that Lua is simple, the syntax changes should hopefully make Lua code even simpler to read too

Is LuaJIT still based on Lua5.1? I wonder why they haven't followed the language spec up to Lua5.5.

> local gauge = direction == "up" ? count + 10 : count - 10

local gauge = count + (direction == "up" ? 10 : -10)

I imagine these changes make the original Lua adepts think their training wheels have come off. The language now looks like any other. That's a good thing to me, and it will help with the adoption of the JIT, but the whole language could have been syntax modernized as a result. But.. when the work is done someone else can fork it into something independent from its Lua roots.

From that perspective the conditional operator seems defensible, where it would be feature creep otherwise, as it is generally unloved elsewhere.

The question is does the coding agent like it or not ?

Please don't, inscrutable bitwise operators are an accident of the past even in systems languages, let alone in a scripting language. I'm not against infix operators for bitwise operations, just please spell them out with keywords rather than giving them sigils.

Likewise, going from `and` and `or` to `&&` and `||` would be a dispiriting regression. This is something that Zig got right.

What’s the Lua/LuaJIT story these days for bundling up all the scripts of an application into a single file? Is there a way to do the super convenient go-like thing?

extensions are detachable/optional, those arent extensions but features

Cool to see this - ergonomic syntax will make it easier to recommend Lua. Hope the PUC team aligns with this.

Also, I love this kind of pragmatism:

> Exponentiation assignment a ^= b has been deliberately omitted to avoid a predictable pitfall: this is how xor assignment is written in most other computer languages. Also, a syntax for exponentiation assignment is rarely asked for.

A ‘defer’ for closing files or deleting temp files at the end of a script will make life more enjoyable.

In aggregate this looks like a godsend, but there are some examples (like foo?.:method) that looks atrocious.

What are some pragmatic embedded scripting languages of choice these days if one has to consider:

1) Ease of learning, ideally minimal deviant behaviour (eg i consider lua tables to be a new concept in itself)

2) Reasonably fast. Not as much as lua jit but even half would be good enough

3) Mature

4) Has Rust bindings

Lua has a lot of useless syntax. For instance, the "then". I have been using ruby and python for many years. Lua is living in the old age here.

That's just one example of so many more. I get that lua occupies a useful niche with its focus on embedded systems, but lua is not really a well-designed language in general. JavaScript has a similar problem.