Earlier quoted context omitted.
not even close, because there are a lot of places where you can't run LuaJIT
Where can you not run LuaJIT? Genuinely curious
anywhere that does not allow self modifying code such as app stores.
LuaJIT 3.0 proposed syntax extensions
51–60 of 170 posts
Re: LuaJIT 3.0 proposed syntax extensions
#52Seems like a bad idea to actively diverge from Lua, hostile even, especially without at least a clear change of name.
Re: LuaJIT 3.0 proposed syntax extensions
#53Lua 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.
[dead]
Re: LuaJIT 3.0 proposed syntax extensions
#54Re: LuaJIT 3.0 proposed syntax extensions
#55Tangently 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?
Re: LuaJIT 3.0 proposed syntax extensions
#56> 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…
> This feels like adding braces to Python because you don't like indenting your code.
Now this I can get behind...
Re: LuaJIT 3.0 proposed syntax extensions
#57Looks 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?
well, it doesn’t say Lua5.1-JIT
Re: LuaJIT 3.0 proposed syntax extensions
#58Earlier quoted context omitted.
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.
I don't think if-expressions have to affect existing semantics. Basically, in the parser you would have two different kinds of AST nodes, one for when the `if` keyword is encountered in statement position and another for when it's encountered in expression position. Right now, `if` in expression position is just a syntax error ("unexpected symbol")
Well, I believe there could be some complications with parsing related to the fact that Lua grammar doesn't really requires semicolons between the statements.
But other than that, yeah, detecting "if" in the expression position is pretty unambiguous. No idea why most languages went with "cond-expr ? then-expr : else-expr" bracketed syntax instead.
Re: LuaJIT 3.0 proposed syntax extensions
#59Earlier quoted context omitted.
Are there any rough estimates on popularity of lua implementations? At this point it feels lua means luajit
not even close, because there are a lot of places where you can't run LuaJIT
LuaJIT is not just a JIT, it also includes high speed interpreters for x86, Arm, and more.
Re: LuaJIT 3.0 proposed syntax extensions
#60Tangently 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.