LuaJIT 3.0 proposed syntax extensions • Hacker News Board

Re: LuaJIT 3.0 proposed syntax extensions

#61

Post by Dylan16807 » Thu, Jun 25, 2026, 4:58 AM UTC

kibwen wrote: post #27

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 kind of person understands and needs bitwise operators but can't easily remember & | ~ and the arrows for shift? It's very little information.

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.

Re: LuaJIT 3.0 proposed syntax extensions

#62

Post by Dylan16807 » Thu, Jun 25, 2026, 5:06 AM UTC

shevy-java wrote: post #44

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.

Python spells "then" as ":"

In Ruby you can choose between "then" and a newline.

This is very pot calling the kettle black.

Re: LuaJIT 3.0 proposed syntax extensions

#63

Post by flumpcakes » Thu, Jun 25, 2026, 5:10 AM UTC

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

Re: LuaJIT 3.0 proposed syntax extensions

#64

Post by spankalee » Thu, Jun 25, 2026, 5:31 AM UTC

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?()`.

Re: LuaJIT 3.0 proposed syntax extensions

#65

Post by _flux » Thu, Jun 25, 2026, 5:39 AM UTC

Joker_vD wrote: post #58

wavemode wrote: post #35

Earlier quoted context omitted.

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.

Re: LuaJIT 3.0 proposed syntax extensions

#66

Post by linzhangrun » Thu, Jun 25, 2026, 5:42 AM UTC

bawolff wrote: post #12

+= 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 ?:

Lua pursues "simplicity, purity, and simplicity." So... too much syntactic sugar is unlikely

Re: LuaJIT 3.0 proposed syntax extensions

#67

Post by doophus » Thu, Jun 25, 2026, 5:56 AM UTC

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.

Re: LuaJIT 3.0 proposed syntax extensions

#68

Post by valorzard » Thu, Jun 25, 2026, 6:08 AM UTC

ianm218 wrote: post #34

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.

[dead]

Re: LuaJIT 3.0 proposed syntax extensions

#69

Post by xonre » Thu, Jun 25, 2026, 6:09 AM UTC

shevy-java wrote: post #44

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 readability, `then` allows splitting with newlines very long conditional expressions, without having to wrap the condition in parentheses:

  if x + y + z > a
    or verylongconditionalhere ()
    or anotherverylongconditionalhere ()
  then
    ...

after `if` and `elseif` the parser simply goes on until it finds `then`.

Re: LuaJIT 3.0 proposed syntax extensions

#70

Post by mjmas » Thu, Jun 25, 2026, 6:10 AM UTC

shevy-java wrote: post #44

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.

English too