Luajit a wonderfully clever piece of code that only one person understands and is able to support. Before everyone chimes in that I'm mistaken ask yourself why Luajit has not evolved to be compatible with the latest Lua 5.3 release.
So unlike those languages Lua can really be considered "done". Version 5.2 was a lot like C99, maybe people considered one or two features "nice to have" but most Lua programmers saw no need to upgrade. Others like Mike Pall even considered 5.2 inferior to 5.1.
Now we have 5.3 which is really all about one special-purpose feature: 64 bit integers. That is a feature most Lua users do not need and it comes with a massive complexity and performance price tag.
Unless you really need 64 bit integer math in your scripts 5.3 is the inferior language.
I really enjoy that in classic Lua a number is a number, that is such a relief compared to the hell that is C's countless numeric types and all the potential bugs resulting from (silent) conversions between them. Lua 5.3 brought that problem to Lua e.g.
a = 9223372036854775000
b = 0.5
c = a + b
c = c - b
print(c) // 9.2233720368548e+18
And of course Lua 5.3 is slower and needs more memory because of the additional complexity which must be handled.
Thanks but no thanks.
I mean Lua 5.3 still makes sense if you really need 64-bit integers in your Lua scripts. But otherwise it is a downgrade.
/ducks
I have little experience in lua myself, and I know only that lua is meant to be a simple language. That said, I can't see from your example what's wrong with lua5.3. I ran the same code with lua5.1, lua5.2, and lua5.3 – and the output was identical across all:
$ diff <(lua5.1 numcheck.lua) <(lua5.3 numcheck.lua)
$ diff <(lua5.2 numcheck.lua) <(lua5.3 numcheck.lua)
$In Lua < 5.3 the value is immediately corrupted (check the value of 'a' after the initial assignment) and static analysis can detect that line as a bug.
In contrast in Lua 5.3 it is perfectly fine code and the value of 'a' will be 9223372036854775000 as one would expect. However the moment you - maybe accidentally - mix that int64 variable with a float64 variable in an expression you end up with a (silent) bug.
Such bugs will happen. They happen all the time in C and in Lua's case things are even worse because function parameters do not have types. The possibilities of hard to find, nasty bugs are endless here. E.g. simply forgetting the second '/' in '//' in one part of the program can cause bugs in a completely different part, maybe even in a third party module, and only under certain circumstances.
That's not true at all, Lua < 5.3 uses doubles for all numbers, which on most computers is IEEE 754, they can represent integers perfectly up to 2^53
The value is not corrupted, depending on the rounding mode is which number you're going to get out of that (I get 9223372036854774784)
I know that of course, but using doubles for integer math is only safe if you limit yourself to a certain integer range.
>which on most computers is IEEE 754, they can represent integers perfectly up to 2^53
False. You get rounding errors after 10^14.
>The value is not corrupted, depending on the rounding mode is which number you're going to get out of that (I get 9223372036854774784)
The above being an example of such a rounding error.
If I assign the value 9223372036854775000 to a variable I expect said variable to afterwards have the value 9223372036854775000 not 9223372036854774784. Your example is exactly what I meant with "corrupted" i.e. the value is changed by the conversion.
He also criticized 128 bits interpreter values mandated by the support of 64 bits integer in v5.3. These take twice as much cache space and damage performance.
However, I was more saying that there isn't a technical reason that lua 5.3 integer behaviour couldn't reuse the existing (boxed) 64bit integer support in luajit. Which would mean that the slim tagged NaN tagged value approach can be kept.
IMO 5.3 should have done what LuaJIT did and require a suffix for 64-bit integer literals (say `L` to avoid conflict with LuaJIT's `LL`). Given how rarely Lua code needs true integers this large, that probably would have worked better. It also would have avoided the gotchas of porting code to 5.3 where the integral numbers you never add `.0` to are suddenly real integers instead of floats.
I'd love for LuaJIT to get 5.3's bitwise ops but the semantic differences between the integer implementations would make this interesting to say the least.
[1]: http://tarantool.org/ [2]: https://github.com/tarantool/tarantool/blob/1.7/src/lua/util...
(somewhat off topic) Mike authored a cunning patch to un-box short strings, sadly it got never mainlined. http://lua-users.org/wiki/FastStringPatch
I suppose the Lua authors wanted to avoid the memory limitations of LuaJIT on 64bits machines.
---- Original below:
I thought v5.2 used NaN tagging but I may be wrong. At least the beta versions did. I misremembered that post to refer to the final version: http://lua-users.org/lists/lua-l/2011-07/msg00180.html
Quoted in full:
----
Lua 5.2 beta implements the "NaN trick": it packs all Lua values into a single double value by representing non-numeric values as signaled NaNs, which are (usually) not produced by the system.
This trick should work on most 32-bit machines that follow IEEE 754-2008 for double representation. However, currently it is being enabled only by predefined macro __i386__ (and similars). We would like to know what other platforms could benefit from this trick (and what macros should we check in luaconf.h). You can force the trick by compiling Lua with -DLUA_NANTRICKLE (for little endian systems) or -DLUA_NANTRICKBE (for big endian).
(Of course, we would also like to know whether there are problems with this implementation.)
-- Roberto
----
I also think I remember people (maybe Mike Pall) reporting perf regressions between 5.2 and 5.3 because of the cache bloat introduced by mandatory 128bits values (on 64bits systems).
I don't have enough context to know if breaking backwards compatibility is justified or not. I generally think it's a poor decision that's hostile to developers to break backwards compatibility in a programming language without providing a clear migration path. Issues between 5.1, 5.2, and 5.3 definitely seem to have splintered the community.
There was a very good reason for this change, which is that Lua introduced an integer type instead of using floating point numbers for everything. This means that LUA_NUMBER_DOUBLE and LUA_NUMBER_FLOAT do not really make sense anymore (when you check those you may want to check the type of the integer numbers or the type of the floating-point numbers).
In any case, porting luabitop doesn't really matter that much: if LuaJIT supported Lua 5.3 people would use the native 64 bit bitwise operators it introduced instead.
[1]: http://tarantool.org/ [2]: https://github.com/tarantool/luajit
P.S. there are shortcoming plans to establish a non-profit foundation to continue development of LuaJIT.
// Disclaimer, I'm a contributor of [1]