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

161–170 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#161

Post by drunken_thor »

nmz wrote: post #160
drunken_thor wrote: post #119

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…

> Const keyword: changing const from `local a = 42` to `const a = 42` is far better syntax. The bracketed syntax was never a good idea. The bracketed syntax is an okay idea especially for , adding close as a keyword would be a disaster given how common the word is. If anything, local should have been tossed away as a keyword and the bracketed syntax adopted completely v , v2 = io.open'file', false g = 5 5.5 introduce…

- Agreed on the bracketed attributes, the close attribute is very useful and devs would reach for the brackets more if they were like as you suggest. - short form fns: you and another commenter have given me good examples. I’m still not sure they are worth the complexity but I understand the use better now. - varargs true! Conceded!

Thanks for the comment! It’s helpful.

Re: LuaJIT 3.0 proposed syntax extensions

#162

Post by krapp »

martinjc wrote: post #159

Say you were to embed a lua engine today. Which implementation would you choose? I also consider syntax important. So if you were to choose what seemed sane, but also something you saw working in 5 years. I am asking because i want to implement plugins in my media server, however i want to guard them in vm's i can control.

My personal opinion, take as you will...

If what you're doing involves any kind of C interop, it's a lot easier to write an API layer in Lua with LuaJIT than it is to do from C with standard Lua. And there's no reason to assume LuaJIT will stop working any time soon. Unless you actually need any of the more modern features of Lua then I'd say go with LuaJIT.

Re: LuaJIT 3.0 proposed syntax extensions

#163

Post by [deleted] »

Dylan16807 wrote: post #158
fsfod wrote: post #149

Earlier quoted context omitted.

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.

5.1 had function environments, then 5.2 changed them from a hidden value to a hardcoded variable name that was easier to change. How did that add extra indirection or slow anything down?

[deleted]

Re: LuaJIT 3.0 proposed syntax extensions

#164

Post by lucas_t_a »

bruce343434 wrote: post #142
aeonflux wrote: post #123

Earlier quoted context omitted.

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

the oposite is also true, you can have misleading side effects coming from joining things into a single expression

Re: LuaJIT 3.0 proposed syntax extensions

#165

Post by nmz »

orthoxerox wrote: post #157
nmz wrote: post #156

Earlier quoted context omitted.

a lone ? can mean anything, you can already tell that . is for fetching a subtable.

In C# it's not a lone ?, it's two operators: ?. and ?[ Lua could have ?. ?[ ?" ?{ and ?(

I'd rather it use ?.() the . means getkey, () means expression using .(expr) should be the same as array[], throwing ? as a character should be very obvious what it does.

Re: LuaJIT 3.0 proposed syntax extensions

#166

Post by genxy »

ianm218 wrote: post #128
genxy wrote: post #55

Earlier quoted context omitted.

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/5ba036…

Thanks for the follow up. It is nice to know that Claude is as horrible a writer for everyone else as it is for me. God it even slipped in load-bearing, hell have mercy on us. I did read (skim) the whole thing.

> Do you have a use case in mind?

Two, 1) upgrading Lua code on a module by module basis 2) Using a newer library on an older codebase. I know those are really two takes on the same problem. I understand why your system doesn't, but at least yours is more flexible than mlua.

I understand why this hard and why it just doesn't work like this out of the box. Lua minor versions are really major and the semantics really does change.

I also don't think what I am asking for is all that necessary, more of a cute language and runtime flex. If the Lua total addressable market was 100x what it is with lots of code on older versions that needed to run side by side then maybe.

Re: LuaJIT 3.0 proposed syntax extensions

#167

Post by martinjc »

krapp wrote: post #162
martinjc wrote: post #159

Say you were to embed a lua engine today. Which implementation would you choose? I also consider syntax important. So if you were to choose what seemed sane, but also something you saw working in 5 years. I am asking because i want to implement plugins in my media server, however i want to guard them in vm's i can control.

My personal opinion, take as you will... If what you're doing involves any kind of C interop, it's a lot easier to write an API layer in Lua with LuaJIT than it is to do from C with standard Lua. And there's no reason to assume LuaJIT will stop working any time soon. Unless you actually need any of the more modern features of Lua then I'd say go with LuaJIT.

The server is actually written in PHP. There is a lua module for php but it has not seen any love since 2020.

Thank you for your advice. Will have to dig to understand what it would take to write an interop for PHP.

Re: LuaJIT 3.0 proposed syntax extensions

#168

Post by ianm218 »

genxy wrote: post #166
ianm218 wrote: post #128

Earlier quoted context omitted.

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/5ba036…

Thanks for the follow up. It is nice to know that Claude is as horrible a writer for everyone else as it is for me. God it even slipped in load-bearing, hell have mercy on us. I did read (skim) the whole thing. > Do you have a use case in mind? Two, 1) upgrading Lua code on a module by module basis 2) Using a newer library on an older codebase. I know those are really two takes on the same problem. I understand why y…

Very cool! Well let me know if you get a chance to use it would love to hear if it ends up being the right tool.

Re: LuaJIT 3.0 proposed syntax extensions

#169

Post by camgunz »

matheusmoreira wrote: post #137
camgunz wrote: post #79

One of the interesting things about Lua is because they don't really maintain compatibility between major versions, there isn't a huge ecosystem, and as a result there's less friction against making your own, slightly incompatible version. When you add on the simplicity of implementing the language, it's created a really diverse set of lua-alikes. Weird (and cool) for a language to have a diverse ecosystem of impleme…

Fragmentation is terrible for a language. Just look at Scheme. Nobody actually uses Scheme itself, it's always some Scheme implementation like Racket, Guile, Chicken, Chez, etc. Languages should probably protect themselves with trademarks or something.

I don't know, Lua is way more successful than Ruby, Dart, Swift, Perl, Kotlin, etc. Something is going right (it's very good for scripting engines).

Re: LuaJIT 3.0 proposed syntax extensions

#170

Post by revengerwizard »

coneonthefloor wrote: post #124

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.

Compatibility with PUC Lua versions after 5.1 is especially hard, given that more or less arbitrary syntactic and semantic but also C API changes have been introduced in every version since then.

That is mostly the reason why LuaJIT is stuck with a mix of 5.1 and toggled 5.2 features.

Post reply on HN