> 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.
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`.
I find that so much harder to read compared to if/else or case/when in ruby.
The ? is basically an attempt to use fewer if/else, at the cost of condensed if-else like structure. I always need to look at both parts after the ? whereas in a single if or elsif I don't. case/when in ruby is even better here e. g. regex check:
def foo(i)
case i
when /^cat/
handle_cats
when /^dog/
handle_dogs
(I ommitted the "end"s here to just focus on the conditional logic.)
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.
Also, one issue I have with this repo is that, since so much of it seems to use Claude, as an actual human I struggle to read and parse any of the information.
This is amazing! Can a program call across versions? Like could we take a Lua 5.1 codebase and upgrade only a portion of it at a time to a new Lua version?
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.
This is the best answer in my opinion. Ternary is just sugar for an expressive if. LuaJIT seems to be focusing on adding new syntax though, maintainer might not be amenable to updating existing semantics.
I don't think if-expressions have to affect existing semantics. Basically, in the parser you would have two different kinds of AST nodes, one for when the `if` keyword is encountered in statement position and another for when it's encountered in expression position.
Right now, `if` in expression position is just a syntax error ("unexpected symbol")
Well, I believe there could be some complications with parsing related to the fact that Lua grammar doesn't really requires semicolons between the statements.
But other than that, yeah, detecting "if" in the expression position is pretty unambiguous. No idea why most languages went with "cond-expr ? then-expr : else-expr" bracketed syntax instead.
Surely the most likely explanation is familiary from C?
But e.g. ml-family languages (like OCaml, F#, Haskell) and Rust just have the *if* expression that has a non-void value. If your language accepts expressions as statements (most do?), then I think that should just be compatible out of the box.
Yes, but why C had that syntax? Oh, right, because it didn't use if-then[-else]-end for the conditional statement, and reusing if(cond)[-else] with prohibited braces would be awkward.
Oh, and Lua most famously does not accept expressions as statements. Which, now that I think of it, would actually evade most of the parsing complications.
I guess for the JS case it makes sense to be able to shave a few characters for file shrinking purposes, but generally I'm more biased to code clarity and "self-explainability"
I find it most useful in languages that have non-mutable variables and you want to avoid a mutable variable or an extra function when the value comes from a simple condition.
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.
That takes me back a bit. It's a perl-ism. I used to think it was a great design feature but I've come to strongly prefer "There should be one way to do it, and it should be obvious"
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.
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.
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.
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?()`.
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?
There's a bunch of options from a Google search, but embedding it in a thin C program and building that with https://github.com/jart/cosmopolitan would be a pretty go-like experience, I'd think.
I personally use a hand-written C wrapper program (which is not much more than a dozen lines long), and then embed the Lua scripts using objdump. This isn't quite as easy as Go since cross-compiling C programs is often somewhat tricky, but Lua is very portable and has zero dependencies, so it's usually not too hard.
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
> It’s nice that Lua is simple, the syntax changes should hopefully make Lua code even simpler to read too
But which Lua?
Lua as implemented by LuaJIT is a fork of the language at this point. It's not fully compatible with PUC Lua (the reference implementation) and LuaJIT does not support features from the latest Lua version.
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.
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.
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.
Now this I can get behind...
Also consider AI, that has a greater training base of JavaScript than Lua. So making Lua look more like JS, should improve output and reduce mistakes.
I'm proud of it and thankfull to the Lua/Luajit projects.
Does that operator compile to faster assembly that if I make the same logic with verbose `if` logic? Is that a language specific outcome?
The ? is basically an attempt to use fewer if/else, at the cost of condensed if-else like structure. I always need to look at both parts after the ? whereas in a single if or elsif I don't. case/when in ruby is even better here e. g. regex check:
(I ommitted the "end"s here to just focus on the conditional logic.)My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
For example, what’s the performance like?
> My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
I think you could stop right before the syntax extension.
Right now, `if` in expression position is just a syntax error ("unexpected symbol")
But other than that, yeah, detecting "if" in the expression position is pretty unambiguous. No idea why most languages went with "cond-expr ? then-expr : else-expr" bracketed syntax instead.
But e.g. ml-family languages (like OCaml, F#, Haskell) and Rust just have the *if* expression that has a non-void value. If your language accepts expressions as statements (most do?), then I think that should just be compatible out of the box.
Oh, and Lua most famously does not accept expressions as statements. Which, now that I think of it, would actually evade most of the parsing complications.
> E.g. true and false or 42 returns 42, whereas true ? false : 42 returns the (expected) false.
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.
What on earth is this supposed to mean?
That takes me back a bit. It's a perl-ism. I used to think it was a great design feature but I've come to strongly prefer "There should be one way to do it, and it should be obvious"
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.
There are real improvements though, such as ?. and ??= that help with default-nullable everything.
Ternary is very useful, but it I'd rather see it implemented idiomatically:
Structural pattern-matching could be fantastic, but no syntax is suggested.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.
So shouldn't it have a new name?
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 ?:
Likewise, going from `and` and `or` to `&&` and `||` would be a dispiriting regression. This is something that Zig got right.
The part I'd call a hassle is the different kinds of right shift but you have that same hassle if you use keywords.
I like using the and/or keywords for logical operations. Now let's make bitwise look significantly different from that.
Edit: meaning he can come back anytime.
But which Lua?
Lua as implemented by LuaJIT is a fork of the language at this point. It's not fully compatible with PUC Lua (the reference implementation) and LuaJIT does not support features from the latest Lua version.
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.
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
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.
In Ruby you can choose between "then" and a newline.
This is very pot calling the kettle black.