Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LuaJIT 3.0 proposed syntax extensions

github.com

Post reply on HN
Print view View original

81–90 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#81

Post by simonask »

Ardren wrote: post #49

> 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 com…

Ruby has both kinds of operators as well, and it's fine. The thing in Ruby, though, is that the English logical operators have lower precedence than the symbolic logical operators, so you can use them in place of parentheses. Sometimes that's confusing, other times it can be used to make code very readable.

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.

Re: LuaJIT 3.0 proposed syntax extensions

#83

Post by boxed »

doophus wrote: post #67
Ardren wrote: post #49

> 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 com…

> Why though? What does changing `and` to `&&` actually achieve? Were people confused? 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.

AI has greater training on Python, which uses `and` and `or`, and it has absolutely no issue keeping that straight.

Re: LuaJIT 3.0 proposed syntax extensions

#84

Post by orthoxerox »

omoikane wrote: post #36

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 t…

LuaJIT is an involuntary fork of 5.1. It already had various extensions that conflicted with the 5.2 implementation of the same features, and Mike Pall made it clear on the mailing list he wasn't going to change how LuaJIT worked.

Re: LuaJIT 3.0 proposed syntax extensions

#85

Post by orthoxerox »

pansa2 wrote: post #2

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.

A bunch of them are from Luau, the Roblox fork of Lua and the dialect most young programmers know. Adding them to LuaJIT will make it easier to write for both Zoomers and AI agents, who have been exposed to a lot of Luau code.

Re: LuaJIT 3.0 proposed syntax extensions

#86

Post by orthoxerox »

matheusmoreira wrote: post #6

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?

Why won't it be compatible? Any code written in Lua 5.1 will run on LuaJIT.

Re: LuaJIT 3.0 proposed syntax extensions

#87

Post by orthoxerox »

JSR_FDED wrote: post #29

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 was a Lua[JIT] fork called Idle that seems to have fallen off the face of the Earth that did exactly that: it would take a small stub program, a runtime library and all the scripts and package them into a single PE/COFF binary that would read itself when run.

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.

Re: LuaJIT 3.0 proposed syntax extensions

#88

Post by noelwelsh »

Heliodex wrote: post #19

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 b…

Exactly. I don't understand why people think the ternary operator is needed when you can just make `if` an expression instead of a statement. Then there is no new syntax to learn and `if` just becomes more useful.

Re: LuaJIT 3.0 proposed syntax extensions

#89

Post by fluoridation »

ricardobeat wrote: post #3

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.

Lua to me always felt very JavaScripty, just with a different syntax.

Re: LuaJIT 3.0 proposed syntax extensions

#90

Post by a-french-anon »

gnubison wrote: post #37
edoceo wrote: post #32

Earlier quoted context omitted.

I love the ternary operator as much as anyone. But dang if it doesn't get hard to read when there is are a few, nested even. 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 If they are truly nested, then that is confusing. But if you have an if-else chain, then it can be quite readable.

Or they could just ask granddaddy for advice:

  (cond (cond1 res1)
        (cond2 res2)
        (cond3 res3)
        (t     else_res))
=)
Post reply on HN