4 ms·

Except luajit has boxed 64bit integers: there's no reason you couldn't have them act just like lua 5.3 64 bit ints. In the majority of real use cases you can na

Except luajit has boxed 64bit integers: there's no reason you couldn't have them act just like lua 5.3 64 bit ints. In the majority of real use cases you can narrow down to the 32bit ints already supported by luajit.

pygy_ 10y ago
Even from the Lua C API standpoint? I'm not very familiar with it.
- daurnimator 10y ago
  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.
  - blep 10y ago
    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.
- rtsisyk 10y ago
  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/ http://tarantool.org/ [2]: https://github.com/tarantool/tarantool/blob/1.7/src/lua/utils.h#L382-L430 https://github.com/tarantool/tarantool/blob/1.7/src/lua/util...

pygy_ 10y ago

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

daurnimator 10y ago
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.
- blep 10y ago
  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.
rtsisyk 10y ago
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/ http://tarantool.org/ [2]: https://github.com/tarantool/tarantool/blob/1.7/src/lua/utils.h#L382-L430 https://github.com/tarantool/tarantool/blob/1.7/src/lua/util...