LuaJIT 64 bit integers (was: the purpose of lightuserdata)

[Mike Pall <mikelu-1101@...>]

Vaughan McAlley wrote:
> On 11 January 2011 23:21, Mike Pall <mikelu-1101@mike.de> wrote:
> > LuaJIT git HEAD already has 64 bit literals and arithmetic
> 
> Out of curiosity, do you intend these 64-bit numbers to be "first
> class" numbers:
> 
> local x = 10LL
> local t = { [x] = "foo" }

Well, I could. But I'm not sure I should ...

I'm already in trouble, because I need to change the standard
rules for comparisons. Cdata objects are a distinct type, but
treating these as unequal to any number or not comparable would be
rather counter-intuitive: e.g. 1LL == 1 should really return true
and 1LL < 2 should return true, too (and not throw an error).

Ok, so comparisons with numbers were never really based on strict
object identity (because 0 == -0 returns true) and that carried on
to table indexing (t[0] and t[-0] reference the same value).

But it's unclear how far one should take this. Lua tables are fast
because they are (mainly) based on object identity and not on
object equality. Once I add int64_t hash equality, somebody will
ask for hash equality for complex numbers, then for structs and
then ask for a __hasheq metamethod. Java hash tables are slow
because they need to take into account all of this.

The good news is that writing your own hash table implementation
(based on whatever equality rules you'd like to have) will be a
lot more efficient with the FFI data structures.

So, unless I hear good reasons for changing this, 64 bit integers
are unsuitable as table keys. You can always use tonumber() to
convert them to plain numbers (limiting the precision to 52 bits).

BTW: I'll push the commits for 64 bit integer comparisons later
     today. Yes, 1LL == 1 works as expected.

--Mike