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

91–100 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#91

Post by childintime »

> local gauge = direction == "up" ? count + 10 : count - 10

local gauge = count + (direction == "up" ? 10 : -10)

I imagine these changes make the original Lua adepts think their training wheels have come off. The language now looks like any other. That's a good thing to me, and it will help with the adoption of the JIT, but the whole language could have been syntax modernized as a result. But.. when the work is done someone else can fork it into something independent from its Lua roots.

From that perspective the conditional operator seems defensible, where it would be feature creep otherwise, as it is generally unloved elsewhere.

Re: LuaJIT 3.0 proposed syntax extensions

#92

Post by [deleted] »

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.

[deleted]

Re: LuaJIT 3.0 proposed syntax extensions

#93

Post by bonoboTP »

nullpoint420 wrote: post #56
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…

> This feels like adding braces to Python because you don't like indenting your code. Now this I can get behind...

You need Bython https://github.com/mathialo/bython

Re: LuaJIT 3.0 proposed syntax extensions

#94

Post by jsomedon »

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.

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.

Re: LuaJIT 3.0 proposed syntax extensions

#96

Post by spider-mario »

simonask wrote: post #81
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 pun…

Same in Perl, hence the good old pattern:

    open my $fh, '

Re: LuaJIT 3.0 proposed syntax extensions

#97

Post by spider-mario »

mjcohen wrote: post #24
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.

Unless you mess up its associativity, like PHP until 7.4.

https://wiki.php.net/rfc/ternary_associativity

http://phpsadness.com/sad/30

Re: LuaJIT 3.0 proposed syntax extensions

#98

Post by ncruces »

Twirrim wrote: post #8
201984 wrote: post #4

Earlier quoted context omitted.

>TIMTOWTDI What on earth is this supposed to mean?

There Is More Than One Way To Do It. That takes me back a bit. It's a perl-ism. I used to think it was a great design feature but I've come to strongly prefer "There should be one way to do it, and it should be obvious"

Using acronyms is one of those ways. /s

Re: LuaJIT 3.0 proposed syntax extensions

#99

Post by Ciantic »

yxhuvud wrote: post #82

In aggregate this looks like a godsend, but there are some examples (like foo?.:method) that looks atrocious.

Yeah, "?." as safe navigation operator even in JS where it already exists is eye-sore. They could use some other single character instead of two characters. Question mark is already doing a lot with ternaries etc.

Instead of obj?.:method?.(…) it would be like obj#:method#(…)

Replace # with your favorite extra character instead of questionmark.

Re: LuaJIT 3.0 proposed syntax extensions

#100

Post by krapp »

orthoxerox wrote: post #85
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.

I know the LuaJIT maintainer(s?) will never add it because it's too radical a departure from Lua but I wish they would include Luau's type annotations. There are typed languages like Teal that will compile to Lua that should work (although I've had a difficult time getting Teal to work with cdefs) and you can kind of fake it by using C structs obviously but having such a feature be native to Lua itself would be nice.
Post reply on HN