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.
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.
I kinda have seen somewhere on internet, that the language design of lua and js(well, ecmascript to be precise) is somehow related. But can't really find the exact reference I have seen.. it was long time ago when I read this.
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.
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.
He left for a break, returned and there was no second break or anything.
I don't want to spam it in repo, so leaving it here: he is kind of a hero doing this work and I (hopefully we) am very grateful for his contribution to this world.
We did have a project some years ago looking at extending LuaJIT on which Tom Fransham did excellent work. Alas, the funder's priorities moved on (as is their right!), so we didn't get to finish it. It was a bit sad, as we (well, mostly Tom) had built up a real head of steam, but c'est la vie. Still, either way, I would never have claimed enough personal expertise with LuaJIT to take over maintainership!
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 think that allowing an if statement to return a value to deal with the ternary introduces a now concept to Lua and that is that the value on the final line of a block is a return value much like Ruby. This changes the logic of the entire language more than adding a ternary. I do prefer the if statement as it allows so much more emergent behaviour, but it does have more implications to consider.
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
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.
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.
I'm going to disagree only because one of the primary use cases for LuaJIT is interop with C and I think there's a case for making the ergonomics match.
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?
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.
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.
> Is the intent to hold LuaJIT fixed against some earlier Lua version (I guess 5.1)
Yeah. PUC-Rio went in a direction that Mike Pall didn't want to follow. Something to do with garbage collector finalizers, if I remember correctly, which is a notoriously thorny issue in every language it exists.
I wouldn't be surprised if their plan is to keep compatible with 5.1 and adopt newer features where feasible/compatible. Luau, another language with the explicit goal of extending Lua 5.1 in a compatible way, has a section in their documentation listing all newer Lua features and detailing why they chose to or not to adopt them <https://luau.org/compatibility/>. The needs of Luau and LuaJIT are different though the reasoning is nonetheless fascinating.
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.
> 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.
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?()`.
var ary = [1,2,3,4]; //Array style declaration, syntax sugar for {}
Is not a good idea. I tried using Haxe with Lua target at some point - the mismatch between what you think you get with [], and what you actually get in Lua, requires either a lot of boilerplate (Haxe compiles [] to Array objects), or a chronic WTF from all the new people reading your code (and from yourself, after a few weeks to months of disuse). If you want [1,2,3], make it behave more like an array - or just leave it out, would be my advice. Lua doesn't have arrays, and adding syntax that suggests it does will be a permanent footgun for your users, I think.
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.
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.
Fragmentation is terrible for a language. Just look at Scheme. Nobody actually uses Scheme itself, it's always some Scheme implementation like Racket, Guile, Chicken, Chez, etc.
Languages should probably protect themselves with trademarks or something.
51 comments
[ 4.1 ms ] story [ 59.9 ms ] threadA 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.
> Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.
I agree. I suggested this on the GitHub issue but got nothing but downvotes.
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.
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 ?:
I don't want to spam it in repo, so leaving it here: he is kind of a hero doing this work and I (hopefully we) am very grateful for his contribution to this world.
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
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.
Likewise, going from `and` and `or` to `&&` and `||` would be a dispiriting regression. This is something that Zig got right.
My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.
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.
Yeah. PUC-Rio went in a direction that Mike Pall didn't want to follow. Something to do with garbage collector finalizers, if I remember correctly, which is a notoriously thorny issue in every language it exists.
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.
I'm proud of it and thankfull to the Lua/Luajit projects.
Languages should probably protect themselves with trademarks or something.