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

111–120 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#111

Post by JBits »

Ciantic wrote: post #99
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.

Is there any reason why they're not considering a single '?' like rust? Is it a parsing issue?

So you'd have: obj?:method(…)

Re: LuaJIT 3.0 proposed syntax extensions

#113

Post by ianm218 »

valorzard wrote: post #72
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.

Also, one issue I have with this repo is that, since so much of it seems to use Claude, as an actual human I struggle to read and parse any of the information. For example, what’s the performance like?

Performance dashboard is linked here https://ianm199.github.io/omnilua/performance.html.

In a mix of official and unofficial benchmarks wall clock performance is ~1.4x as fast as C Lua and the memory usage is ~1.7x.

So performance is worse to be clear but within range. There’s some performance improvements I haven’t gone for yet that would get it down to ~1.1 I think.

Re: LuaJIT 3.0 proposed syntax extensions

#114

Post by froh »

gnubison wrote: post #37
edoceo wrote: post #32

Earlier quoted context omitted.

I love the ternary operator as much as anyone. But dang if it doesn't get hard to read when there is are a few, nested even. Does that operator compile to faster assembly that if I make the same logic with verbose `if` logic? Is that a language specific outcome?

cond1 ? res1 : cond2 ? res2 : cond3 ? res3 : or_else_res If they are truly nested, then that is confusing. But if you have an if-else chain, then it can be quite readable.

or

  if cond1 then res1
  else if cond2 then res2
  else if cond3 then res3
  else or_else_res
or

  if cond1 then res1
  elif cond2 then res2
  elif cond3 then res3
  else or_else_res
what is most lua-like?

Re: LuaJIT 3.0 proposed syntax extensions

#115

Post by drdexebtjl »

fluoridation wrote: post #89
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.

Lua to me always felt very JavaScripty, just with a different syntax.

Lua predates JavaScript by about 2 years though.

Re: LuaJIT 3.0 proposed syntax extensions

#116

Post by kzrdude »

mid-kid wrote: post #112

LuaJIT has held back the lua ecosystem for over a decade. There's no reason to not at least try to move the implementation closer to luau or puc lua, not create yet more incompatible syntax

I don't think Lua is your average ecosystem. Lua is used as an embedded interpreter. For example, Neovim doesn't want to change its configuration language's syntax just because there is a new version of Lua available.

On the contrary, we can claim that luajit has stabilized lua for implementations and for users (strengthening Lua 5.1 dominance, which makes the experience more homogenous across apps).

Re: LuaJIT 3.0 proposed syntax extensions

#117

Post by BobBagwill »

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"

TCBOO, AKA, the Highlander Conjecture.

Re: LuaJIT 3.0 proposed syntax extensions

#118

Post by [deleted] »

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

[deleted]

Re: LuaJIT 3.0 proposed syntax extensions

#119

Post by drunken_thor »

Some of these things are already implemented in PUC Lua. I don't know why they are diverting from lua spec on other aspects though. Why not work together with the PUC Lua team to add some of these to both lua versions and work on bringing their functionality closer to each other instead of further apart. You might as well just make a new language instead. New features will end up not being used in effort to keep lua scripts portable.

In effort to not pollute the github issue, and hopes that the authors read this thread, I will put some of my thoughts here. There are 3 main strengths of Lua: Embeddable, Fast, and Small(easy to learn). I worry some of these changes divert from the last, expanding the language into a more complicated language.

Here is a list of things already implemented in PUC Lua so can be considered safe to add:

  ● ~ a     Bitwise negate
  ● a & b   Bitwise and
  ● a | b   Bitwise or
  ● a ~ b   Bitwise Xor
  ● a > b  Logical right-shift
  ● a // b  Floor divide
  ● break   Break statement
Don't get me wrong, I love some of these quality of life changes like:

  ● Const keyword: changing const from `local a  = 42` to `const a = 42` is far better syntax. The bracketed syntax was never a good idea.
  ● nil-Coalescing and safe navigation are great additions as they are basically macros at the parsing stage.
  ● Compound assignment is also basically a macro at the parsing stage as well. Lua should already have this honestly.
  ● Ternary Operator: I *like* it and it will help the stumbling block of the `a and b or c` common pattern already in use. Though I think (like others have stated) the If/then/else syntax would be more inline with the language, similar to ruby and would enable far more emergent behaviour. However it does establish a new pattern that the last value in a block is a return value similar to ruby so I am conflicted about that.
  ● `continue` it is nicer than a goto and is helpful.
  ● String interpolation: I honestly don't love lua's concat operator `..` so honestly string interpolation would be a nice to have and a feature of many modern languages. However I do worry about it's effect on parsing performance, and complexity of the language.
  ● Underscores in numbers: *shrug*
These are great ideas for the language but I would want all lua versions to support them, not just JIT. These are things that I think are a distraction:

  ● The `and` `&&` and `or` `||`. This just goes in the wrong direction for lua. It is often confusing in ruby (especially because of precedence issues) but also lua is a wordy language. It has `do` `end` blocks instead of brackets. It adds ambiguity for no reason.
  ● Short form function syntax. Lua does not need this and I am not sure anyone asked for this. Why `a = |x| do ... end` is more helpful than just `a = function(x) ... end` is unclear and would love to hear more about why this is being considered.
  ● Named varargs: It may be nice, but there is no real reason to add this. If you wanted a name for your varargs you could do `local name = ...` or just use the `args` variable already available in every function.
  ● Switch/Match/Select Statements: An optimized if/else block works just as well and another expansion of a small language.

Re: LuaJIT 3.0 proposed syntax extensions

#120

Post by otikik »

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.

In Lua (and LuaJIT) you can already use `and` and `or`:

    local x = y and y + 1 or 0
The knuckle heads are already using them everywhere.
Post reply on HN