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...
In general, I would expect symbolic operators to be desirable in complex boolean expressions, because "loud punctuation" stands out among English words when reading the code.
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.
Does that operator compile to faster assembly that if I make the same logic with verbose `if` logic? Is that a language specific outcome?
cond1 ? res1 :
cond2 ? res2 :
cond3 ? res3 :
or_else_res
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
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.
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.
I'm proud of it and thankfull to the Lua/Luajit projects.
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.
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:
pos += (if forward then +1 else -1)
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.
local x = condition ? value_a : value b
local x = condition and value_a or value_b> E.g. true and false or 42 returns 42, whereas true ? false : 42 returns the (expected) false.
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.
[1] https://en.cppreference.com/cpp/language/operator_alternativ...
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.
This stuff (especially the ternary) are a step backwards. There is just no reason to waste | on a bitwise or that gets used at 1% of the frequency of the standard or. In the future you might have a better use for it (pipeline syntax, sum or union types come to mind in other languages).
I dislike basically everything about these syntax extensions.
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.
Love2D does it as well: zip -9 -r SuperGame.love . cat love.exe SuperGame.love > SuperGame.exe
This doesn't work with ELF files, though.
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.
if x + y + z > a
or verylongconditionalhere ()
or anotherverylongconditionalhere ()
then
...
In Ruby you can choose between "then" and a newline.
This is very pot calling the kettle black.