It was thus said that the Great Soni L. once stated:
Oh, so to clarify (kind of making the bigint library up):
bi = require "bigint"
x = bi.make(2^128) -- syntax issues but I want something
y = bi.make(2^128) -- really really large
t = {}
t[x] = "booya!"
print(t[y])
booya!
As it stands now, Lua will treat x and y as distinct values whereas Soni
doesn't consider them distinct values (because they're distinct uservalues).
Oddly enough, Common Lisp *may* treat to values as distinct, i.e. 2 does
not necessarily eq 2 in CL (they may eql and equal, but not eq). Common
Lisp gets around this by using different forms of equality testing.
Why isn’t this just an exercise in interning, and so just a property of the (hypothetical) bigint library? That is, for any given big integer X, the returned user data is always the same. This also makes equality cheap. Of course there are implementation issues (several occur to me), but it avoids the nasties around __key...
For example, what happens when __key starts returning different values each time it is used? What happens if it returns a very restricted range of keys (and hence stresses Lua’s hash collision processing)? How are collisions avoided for __key values? Remember that __key isn’t returning a hash, it’s returning the definitive unique identifier for that userdata, and Lua assumes these are guaranteed unique for a given type (the hash need not be, of course).
—Tim
