131–140 of 170 posts
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.
Earlier quoted context omitted.
That’s why “if” should just be an expression
This is the best answer in my opinion. Ternary is just sugar for an expressive if. LuaJIT seems to be focusing on adding new syntax though, maintainer might not be amenable to updating existing semantics.
Zig and Rust have addressed the problem of how the result of a block expression should be presented, but neither solution seems particularly satisfying to me.
In Rust, blocks may end with an expression, giving them a non-void result. But a block may also end in a statement, the only difference being that the statement ends in a semicolon, in which case the expression still has the void result, and I think that semicolon being the only difference makes it hard to scan at a glance where values come from.
In Zig, blocks may give non-void results by `break`ing out of them with an expression. But break normally ignores blocks and break out of loops only, so to break out of blocks you have to provide a label for it and give that when you break so as to break out of the named block and not the outer loop, e.g. `const x = label: { break :label 35; }`. That creates a problem of one of the most difficult classes in software engineering: naming things. Ideally I think `break` from a block should have its own keyword, e.g. `const x = { give 35; }`
Is LuaJIT still based on Lua5.1? I wonder why they haven't followed the language spec up to Lua5.5.
Earlier quoted context omitted.
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(…)
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.
Looks like LuaJIT is really going to fork away from Lua this time. After these changes, it won't be a compatible Lua 5.1 implementation anymore, it will be a new language. So shouldn't it have a new name?
Why won't it be compatible? Any code written in Lua 5.1 will run on LuaJIT.
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…
Languages should probably protect themselves with trademarks or something.
So is LuaJIT resuming active development after a decade or so of only maintenance? Great! A lot of these changes make sense (although some of them are a bit too TIMTOWTDI for my taste) - but perhaps LuaJIT 3 would benefit from a change of name as well? Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.
> Certainly with all these changes, it would be more like a separate language than merely a JIT-compiled version of Lua.
I agree. I suggested this on the GitHub issue but got nothing but downvotes.
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…
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.