Hacker News Reader

Comment by pygy_ | Hacker News Reader

Even from the Lua C API standpoint? I'm not very familiar with it.

Tarantool[1], a general-purpose database and app server based on LuaJIT, has Lua/C API to work with 64-bit numbers and even custom cdata objects [2]. I can extract this code into a separate library for you.

[1]: http://tarantool.org/ [2]: https://github.com/tarantool/tarantool/blob/1.7/src/lua/util...

Currently in luajit you're just "not meant to" work with ffi cdata from the C api. You can... even if it's not pretty.

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.

I think the main problem here is that there are several semantic differences between 5.3's and LuaJIT's integers which would make this a bit dodgy; eg. rounding behavior and mixed float-integer arithmetic are different.

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.

Reply on news.ycombinator.com