lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 19/07/16 06:59 PM, Sean Conner wrote:

It was thus said that the Great Soni L. once stated:

As I and others have noted, the functionality needed by the OP can be
done by interning, or by the appropriate use of metatables.

With returning plain integers (for interoperability with plain Lua keys)
I'd have to use bigint.add(bigint(1), bigint(2)) instead of bigint(1) +
bigint(2), which makes it literally impossible to write code that works
with both bigints and plain numbers.

   I would like to see the code you have, right now, that does not work
because of this issue.  What *actual problem* are you trying to solve that
the lack of __key is preventing you from continuing further.

   No, I don't want "it would be nice to have this feature".  I want the
actual code that is currently failing for you, right now.  What is the
actual issue?  Because there are times when I suspect you are trying for a
theoretical purity in implementation of an idea, not an actual problem for
which there is what you want is the only solution (but that's just my take).
I didn't create it, and I don't have access to it, but one of the LuaConf talks was about stored procedures.
The DB has a "decimal" datatype. Say you have some decimals and you want to put them in a table like so: 

local t = {}
-- assume that decimal() returns interned values
t[decimal("1")] = "c"
t[decimal("2")] = "b"
t[decimal("3")] = "a"

So now you pass the t to code you don't control:

sort(t)
The code doesn't know about decimals, so when calling sort on it you'd get what you started with. I assume this can happen in a DB, however unlikely that is.
If decimal() returned integers or floats depending on the value, then you could get weird things like:
local part = decimal("10")/decimal("100") -- decimal("0.1") would return a proper decimal 
print(part+part+part+part+part+part+part+part+part+part == 1.0) --> false

If you were using decimals to store monetary values, this would be very bad.
You can patch the VM to make this work right, and that's what the DB guys did. However, that means they're locked onto a single patched VM version, and upgrading/changing versions means writing a new patch. The __key proposal would instead provide a stableish API so you could switch Lua/VM versions without too much trouble, as most other extensions could be trivially implemented through preprocessing (by replacing `load`) (e.g. turning `x := (expr)`, the syntax for type-converting assignment, into `x = typeconv(x, (expr))`). The only reason this __key thing can't be done in preprocessing is because it would involve turning every single `t[x]` into `t[tokey(x)]` which is (in theory) significantly slower than just checking for __key in the VM.
This isn't a "this would be nice to have" proposal, this is a "I wanna help these people" proposal. They have a usecase for it, and it would be useful for many of us as well. But I really just wanna help these people. 
   -spc (Yes, in theory, you can create a computer with only a single
	instruction, but then performance becomes an issue ... )




--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.