Live data from Hacker News

LuaJIT 3.0 proposed syntax extensions

github.com

101–110 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#101
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.

I'm going to disagree only because one of the primary use cases for LuaJIT is interop with C and I think there's a case for making the ergonomics match.

Re: LuaJIT 3.0 proposed syntax extensions

#102
post #16

I’m confused I thought Mike Pall left luajit and Laurence Tratt took over as maintainer?

He left for a break, returned and there was no second break or anything.

I don't want to spam it in repo, so leaving it here: he is kind of a hero doing this work and I (hopefully we) am very grateful for his contribution to this world.

Re: LuaJIT 3.0 proposed syntax extensions

#103
post #16

I’m confused I thought Mike Pall left luajit and Laurence Tratt took over as maintainer?

He left for a break, returned and there was no second break or anything. I don't want to spam it in repo, so leaving it here: he is kind of a hero doing this work and I (hopefully we) am very grateful for his contribution to this world.

Are there great uses of LuaJIT out there? It was such a big thing before fast JS engines IIRC.

Re: LuaJIT 3.0 proposed syntax extensions

#105

Earlier quoted context omitted.

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, '

yes, ruby inherited this from perl, though 'or' has lower precedence than 'and' in perl, and they're equal in ruby. Which sounds like something going to cause mistakes, but I yet to see 'and' and 'or' together in the same expression in ruby.

Re: LuaJIT 3.0 proposed syntax extensions

#107

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.

There's some overlap in the languages they were inspired by (eg Scheme, or the chains Modula -> Lua vs Modula -> Java -> Javascript), but as far as I'm aware, the original designs were made independently.

Now, the object systems do look similar, but that seems to be a case of convergent evolution: Javascript took direct inspiration from Self, whereas Lua's system is based on a more generic fallback mechanism for table access.

Re: LuaJIT 3.0 proposed syntax extensions

#108
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…

I've always found it odd that and/or in Ruby isn't just considered equal to &&/||, and I have never really used the english operators except for the usual modifiers like if and unless.

What is a practical use case where the lower precedence makes sense?

Re: LuaJIT 3.0 proposed syntax extensions

#110
post #21

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.

[deleted]
Post reply on HN