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.
LuaJIT 3.0 proposed syntax extensions
101–110 of 170 posts
Re: LuaJIT 3.0 proposed syntax extensions
#102I’m confused I thought Mike Pall left luajit and Laurence Tratt took over as maintainer?
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
#103I’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
#104They 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?()`.
obj?.:method(…)Re: LuaJIT 3.0 proposed syntax extensions
#105Earlier 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, '
Re: LuaJIT 3.0 proposed syntax extensions
#106Re: LuaJIT 3.0 proposed syntax extensions
#107I 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.
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> 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…
What is a practical use case where the lower precedence makes sense?
Re: LuaJIT 3.0 proposed syntax extensions
#109Re: LuaJIT 3.0 proposed syntax extensions
#110I 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.