[lifthrasiir]

> Why Lua 5.1 and not 5.2 or 5.3?

Each version of Lua since 5.1 is basically equivalent to Python 2 and 3, subtly different enough that you have no clear migration path. (And worse, Lua didn't even have an equivalent to 2to3.) So many applications are stuck at 5.1.

I think that there is a decent chance for other implementations to overtake PUC-Rio Lua if this missing migration path is clearly laid. The starter would be implementing all versions at once and allowing the mix of codes written for different versions.

[gnramires]

Do note that Lua is a quite small and simple language. While the difference in internals are significant (hence LuaJIT staying on 5.1), in terms of usage it's just a handful of changes (see here [1] and [2]). The difference with python is that they are not backwards compatible, so even if they're small they might break projects.

This is a double-edged sword, it allows unashamed modifications but it does require rewrites.

Hopefully things settle with 5.4. I love how small and comprehensible the language is.

> The starter would be implementing all versions at once and allowing the mix of codes written for different versions.

I don't think this is quite possible, because some formatting and function return minor details that changed that would break interoperability. That said, porting between versions shouldn't be difficult. Just using the latest version would be the easier and safer solution.

[1] http://www.lua.org/manual/5.2/manual.html#8

[2] http://www.lua.org/manual/5.3/manual.html#8

[lifthrasiir]

> While the difference in internals are significant (hence LuaJIT staying on 5.1), in terms of usage it's just a handful of changes.

Lua doesn't care about older versions for migration, so its changes tend to be more impactful than it looks. If you write a new code for newer versions you don't need to relearn or unlearn much, but for example `0x7fffffffffffffff + 1` was 9.2233720368548e+18 before Lua 5.3 and is now -1. Can you guarantee that your code is free of such overflows? Can you find all overflows before the migration? This very issue prevented me and my team from migrating to 5.3.

LuaJIT is a different situation by the way, AFAIK it stayed with 5.1 because it allows for more efficient implementation. Mike Pall does share some of my criticisms to Lua as well [1].

[1] For example, http://lua-users.org/lists/lua-l/2011-10/msg00578.html or https://www.freelists.org/post/luajit/Port-bitop-to-53,1

[gnramires]

> Can you guarantee that your code is free of such overflows?

Well, according to the manual, you can by appending '+0.0' (or '.0'?) to numbers, converting it to float (tested on Lua 5.4 even hex '0xf...f' can be written as '0xf...f.0').

I don't quite understand the change in terms of language design -- if integer was necessary surely an integer library would be sufficient? I find it a little "too smart for its own good" (in the sense of being unreliable in practice). Perhaps they could have gone for a more separate integer type? For my use cases however, I don't expect to run into any problems (9.2e18 is a very large number).

> Mike Pall does share some of my criticisms to Lua as well [1].

Yes, it makes me sad they broke compatibility so much. I mean, 4 different versions in use is a lot. Hopefully 5.4 is stable now.

[lifthrasiir]

> Well, according to the manual, you can by appending '+0.0' (or '.0'?) to numbers, converting it to float.

In addition to making extensive changes to the code, this is not complete because there are plenty of functions that would return integer instead of numbers (e.g. tonumber).

> Perhaps they could have gone for a more separate integer type?

I too think JS did the right thing: it introduced a new type for integers, and took it as a chance to make it arbitrary precision.