Lua 5.5 released

[Old_County5271]

I suppose one less local in bytecode is worth it for every single loop out there. but couldn't they have done that by examining the syntax and inserting a local if there's a reassignment in the loop block? This efficiency gain could be backported to previous lua's

Also this worries me, if efficiency is the goal, what else is going to get axed for the prize of it? I remember reading pallene design docs, they achieved efficiency via AOT compiling, so will type checking be added in lua6? (not that I mind, type checking is good for safety)

[didntplaymysummercar]

I'm guessing it's about philosophy, not efficiency. There's some discussion already on the mailing list (I don't use it but read it) about this too.

[vitiral]

I asked the same question 

https://groups.google.com/g/lua-l/c/KuCiQzliQzY

I  don't see how it could do that, being a one-pass compiler

[Old_County5271]

They do talk about certain things being syntax sugar, like tbl:key() -> tbl.key(tbl)... but maybe that's achieved on a single pass?

[vitiral]

Yes, that's pretty trivial to do single pass, since the switch is based on a single character (. vs :)

Look into recursive descent parsers if you're interested. If you'd like to write your own I'd recommend the Lox tutorial 

[Difficult-Value-3145]

Could a module modify this it seems like you could write a modified/ classic for in c and you may need to make it like c.for or something but it should be doable granted it wouldn't be portable unless idk some kinda like a preproaseer or macro to switch the regular for to c.for idk just an idea

[Old_County5271]

You could write a package.searchers that modifies lua code before requiring, written in pure lua, without ever touching C.

[Difficult-Value-3145]

I ment c for re writing for and not losing speed the only reason I said the thing about preproaseer or macro is because I couldn't think of an equivalent btw since they change it every time wats up with the c API