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

141–150 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#141

Post by ianm218 »

lifthrasiir wrote: post #60
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.

Oh wow, seriously, I always thought Lua should have been like this. The 5.1/5.2/5.3+ split was so painful. > My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier. I think you could stop right before the syntax extension.

Heh I was going to queue up a skill that uses the CLI to make it easy to convert scripts to older or newer versions.

If you have any Lua use cases let me know I’m looking for more real world use use cases to justify the effort here.

Re: LuaJIT 3.0 proposed syntax extensions

#142

Post by bruce343434 »

aeonflux wrote: post #123
noelwelsh wrote: post #88

Earlier quoted context omitted.

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.

Because you can deduplicate certain parts of the logic which make the whole thing less error prone, such as

    if c
      x=1
    else
      x=2
If I ever want to change x, or refactor this code some other way, its a more brittle process over x=c?1:2

The ternary expression also takes up much less space so there is less of an emphasis on it, this can be a stylistic tool in a programmer's toolbox

Re: LuaJIT 3.0 proposed syntax extensions

#143

Post by Heliodex »

drunken_thor wrote: post #125
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.

I suppose, though I feel what most people in this thread are thinking of is updating the existing if statement to also work as an expression, which does have plenty of implications (not that I think they would be bad, just more of a change to the language than the feature designers were going for) including final returns. The example I took from Luau still keeps the if statement and the if-then-else expression as separate constructs. One problem is that the statement and expression versions look very similar despite having different semantics (expression version must only contain expressions in its branches, must have an `else` case, does not have `end`).

Of course there are differences between LuaJIT and Luau that I think influence their decisions on possible ternary expression features:

- Luau users are disproportionately beginners to programming that I believe would find the if-then-else expression syntax easier to learn; LuaJIT developers have a larger user base of professional devs wanting to make their code faster, and they will probably be more familiar with the `x ? y : z` style since it's used in plenty of other languages.

- Luau is a lot faster moving in its development than LuaJIT in terms of language features, the Luau team just wanted to move people to ternaries from `x and y or z` because it's easier to optimise in a normal interpreter; LuaJIT, with their JIT, I assume would be able to more easily implement optimisations for constructs like `x and y or z` despite its slight semantic differences (my assumption on why the change is being considered now rather than earlier).

Re: LuaJIT 3.0 proposed syntax extensions

#144

Post by ltratt »

le-mark wrote: post #16

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

We did have a project some years ago looking at extending LuaJIT on which Tom Fransham did excellent work. Alas, the funder's priorities moved on (as is their right!), so we didn't get to finish it. It was a bit sad, as we (well, mostly Tom) had built up a real head of steam, but c'est la vie. Still, either way, I would never have claimed enough personal expertise with LuaJIT to take over maintainership!

Re: LuaJIT 3.0 proposed syntax extensions

#145

Post by nmz »

201984 wrote: post #11
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.

Lua basically already has ternary operators anyway since "and" and "or" short circuit. I also don't see the need of adding additional syntax for it. local x = condition ? value_a : value b local x = condition and value_a or value_b

No, not basically, it simply doesn't have them, Ternary means three as in it operates on 3 operands, and/or operates on 2 operands. They are also not equivalent.

   x = a ? b : c # x is b, same as you would if a {x=b} else {x=c}
lua and/or

    a,b,c = true, 1, 2
    x = a and b or c -- x is b


    a,b,c = true, false, 2
    x = a and b or c -- x is c
The or is dependent on its previous operand, so b will return false and skips to c, even if you meant for it to be b. you must use an if then else. However, you can have more than a ternary, if there is no need for short-circuit evaluation, as in, any of the operand is not a function CALL like c(), and you want to remain inside an expression, then you can do this instead

select (select is a native C function, this is faster than the table creation below)

    x = select(a and 1 or 2, b, c)
table creation/selection

    x = ({false,2})[a and 1 or 2]
of course, doing something like

   local x; if a then x=b else x=c end
does not look so bad

Re: LuaJIT 3.0 proposed syntax extensions

#146

Post by nmz »

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`.

This is something I don't see a lot of people do. I've tended to do

  for long,list,of,variables,here
  in ageneratorhere(bigparameterhere)
  do
  end
and

  local x do
    -- everything after is just here to define x
  end
I'm still a little irked it works so well, the only alternative would be for the language to have labeled blocks. but that might be too terse

Re: LuaJIT 3.0 proposed syntax extensions

#147

Post by pynappo »

swah wrote: post #103
misiek08 wrote: post #102

Earlier quoted context omitted.

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.

Off the top of my head, openresty, neovim, love2d

Re: LuaJIT 3.0 proposed syntax extensions

#149

Post by fsfod »

matheusmoreira wrote: post #139
omoikane wrote: post #36

Lua 5.3 (2015-01-12) added the bitwise operators: https://www.lua.org/versions.html#5.3 https://www.lua.org/manual/5.3/manual.html#3.4.2 Looks like LuaJIT is catching up, but calling these "syntax extensions" is confusing. Is the intent to hold LuaJIT fixed against some earlier Lua version (I guess 5.1) and adopt newer syntax piecemeal? I welcome the compound assignment operators. Playdate's version of Lua also has t…

> Is the intent to hold LuaJIT fixed against some earlier Lua version (I guess 5.1) Yeah. PUC-Rio went in a direction that Mike Pall didn't want to follow. Something to do with garbage collector finalizers, if I remember correctly, which is a notoriously thorny issue in every language it exists.

I think it was more the extra layers of indirection added to function environment\effectively global variable access added in 5.2 .

The removal of scanning for changed userdata finalizer meta method in 5.2 is just a commonsense fix for bad design that made GC atomic phase run time, thats not incremental scale up with the number of GC userdata objects alive no matter if they have a finalizer or not.

Re: LuaJIT 3.0 proposed syntax extensions

#150

Post by Heliodex »

omoikane wrote: post #36

Lua 5.3 (2015-01-12) added the bitwise operators: https://www.lua.org/versions.html#5.3 https://www.lua.org/manual/5.3/manual.html#3.4.2 Looks like LuaJIT is catching up, but calling these "syntax extensions" is confusing. Is the intent to hold LuaJIT fixed against some earlier Lua version (I guess 5.1) and adopt newer syntax piecemeal? I welcome the compound assignment operators. Playdate's version of Lua also has t…

I wouldn't be surprised if their plan is to keep compatible with 5.1 and adopt newer features where feasible/compatible. Luau, another language with the explicit goal of extending Lua 5.1 in a compatible way, has a section in their documentation listing all newer Lua features and detailing why they chose to or not to adopt them https://luau.org/compatibility/>. The needs of Luau and LuaJIT are different though the reasoning is nonetheless fascinating.
Post reply on HN