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

21–30 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#21

Post by nine_k »

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.

Worse, I see C (as in ! or &&), and Perl (as in manifestly more than one way to do it).

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)
Structural pattern-matching could be fantastic, but no syntax is suggested.

Re: LuaJIT 3.0 proposed syntax extensions

#23

Post by Rohansi »

larrry wrote: post #20

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.

Re: LuaJIT 3.0 proposed syntax extensions

#24

Post by mjcohen »

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…

The ternary operator is easy to nest if you put each clause on a separate line. Then it looks just like nested if-then-else.

Re: LuaJIT 3.0 proposed syntax extensions

#25

Post by sourcegrift »

What are some pragmatic embedded scripting languages of choice these days if one has to consider:

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

Re: LuaJIT 3.0 proposed syntax extensions

#26

Post by JSR_FDED »

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.

Re: LuaJIT 3.0 proposed syntax extensions

#27

Post by kibwen »

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.

Re: LuaJIT 3.0 proposed syntax extensions

#28

Post by sourcegrift »

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?

Are there any rough estimates on popularity of lua implementations? At this point it feels lua means luajit

Re: LuaJIT 3.0 proposed syntax extensions

#30

Post by JSR_FDED »

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.

The btiwise operators library doesn’t go away
Post reply on HN