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

121–130 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#121

Post by Dylan16807 »

Mond_ wrote: post #78
Dylan16807 wrote: post #61

Earlier quoted context omitted.

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.

It's not about having to remember them, it's that you shouldn't waste these short single symbols on operations that are only rarely used. This stuff (especially the ternary) are a step backwards. There is just no reason to waste | on a bitwise or that gets used at 1% of the frequency of the standard or. In the future you might have a better use for it (pipeline syntax, sum or union types come to mind in other languag…

Lua is very unlikely to want to add newer/less-common syntax with special symbols.

Also a syntax for types can repurpose most symbols without being ambiguous.

And you can overload the bitwise operators. You can configure __bor to give you pipelining right now.

Re: LuaJIT 3.0 proposed syntax extensions

#122

Post by aeonflux »

ClikeX wrote: post #108
simonask wrote: post #81

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…

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?

Those two behave in the same way if you drop the parentheses:

1. statement if (condition || something)

2. (statement if condition) or something

Re: LuaJIT 3.0 proposed syntax extensions

#123

Post by aeonflux »

noelwelsh wrote: post #88
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…

Exactly. I don't understand why people think the ternary operator is needed when you can just make `if` an expression instead of a statement. Then there is no new syntax to learn and `if` just becomes more useful.

I don't really understand where is this need to compress the logic into where small chunks comes from. In result we get single line of code which has multiple statement conditions, different paths, and it's not possible to grasp in one go.

Other practical example why ternary is bad: Many code-coverage solutions break on ternary because they don't correctly see that one of the branches was missed in tests.

Re: LuaJIT 3.0 proposed syntax extensions

#124

Post by coneonthefloor »

The syntax proposals look fine. But I don’t feel they are needed. Lua is easy to write and grok. I default to using LuaJIT, and have never had an issue with the actual code. Integration with the Lua ecosystem is the problem. Fix the compatibility issues with LuaRocks packages and PucRio. That would be the best dev ex update in my opinion.

Re: LuaJIT 3.0 proposed syntax extensions

#125

Post by drunken_thor »

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…

I think that allowing an if statement to return a value to deal with the ternary introduces a now concept to Lua and that is that the value on the final line of a block is a return value much like Ruby. This changes the logic of the entire language more than adding a ternary. I do prefer the if statement as it allows so much more emergent behaviour, but it does have more implications to consider.

Re: LuaJIT 3.0 proposed syntax extensions

#126

Post by rirze »

demilicious wrote: post #15
3eb7988a1663 wrote: post #7

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

That’s why “if” should just be an expression

As long as the language supports lazy evaluation and short-circuiting through expressions, then great.

Re: LuaJIT 3.0 proposed syntax extensions

#127

Post by boomlinde »

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.

I can't imagine that making the differences between the languages more subtle would improve the performance of chatbots. Subtleties aren't their strong suit.

Re: LuaJIT 3.0 proposed syntax extensions

#128

Post by ianm218 »

genxy wrote: post #55
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.

This is amazing! Can a program call across versions? Like could we take a Lua 5.1 codebase and upgrade only a portion of it at a time to a new Lua version?

Hmm I think in general I would not recommend doing this just because Lua does change pretty significant things from 5.1-5.5 so you could have some really hard to understand behavior if some portions are 5.1 vs 5.4 for example.

I think where it would be most helpful is converting a codebase and being able to easily run tests to ensure behavior is the same.

I created a github gist https://gist.github.com/ianm199/5ba0366376eca673142e1f0c79b4... that explains what is practical (I used AI for this to be clear feel free to skim).

Do you have a use case in mind? Would love to chat or take a look at an github issue if you create one.

Re: LuaJIT 3.0 proposed syntax extensions

#129

Post by drunken_thor »

xonre wrote: post #69
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`.

Agreed, it keeps the parser fast as well because it is a lot more clear when the boolean statement ends and the code block begins. You either need parentheses, `then` or brackets around the block to make parsing clearly defined.
Post reply on HN