Re: [Feature Request?] __key

["Soni L." <fakedme@...>]

On 20/07/16 02:46 AM, Tim Hill wrote:
> > On Jul 19, 2016, at 3:26 PM, Soni L. <fakedme@gmail.com 
> > <mailto:fakedme@gmail.com>> wrote:
> >
> > 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.
>
> So really this is about creating first-class types in Lua. For 
> example, creating a bigint or decimal type that appears to the 
> end-user to be as integrated into the language as string or integer. I 
> will note in passing that C++ has been trying to do that for 20+ years 
> with only limited success and only by the creation of a language that 
> rivals PL/1 in complexity (note: C++ fans need not flame me).
>
> And of course in Lua the way you do this is with a metatable on the 
> userdata. So your new type can have addition, subtraction etc. And if 
> you supply __lt then sort() will work just as expected.
>
> So why the need for __key? It seems to me, based on your posts, that 
> this is an attempt to borrow the behavior of an existing type. What 
> you seem to be trying to do is say “look, this type XXX is different, 
> but it’s so like an integer (or float or whatever) that for many 
> things you can treat it like one”. So the table *thinks* it’s an 
> integer (in fact, it IS an integer as far as the table is concerned) 
> and you don’t have to write all those tedious metamethods.
>
> But in fact you DO have to write all those tedious metamethods, 
> because a decimal ISNT a float or an integer, and a bigint ISNT an 
> integer either. Trying to make it kinda-sorta look like one is 
> perilous; you are going to lull your users into thinking that it IS 
> one and then they are in trouble. What happens when they store a 
> bigint that is too big for an integer?
>
> Thus this all comes down to two things: (a) writing the necessary 
> metamethods, and (b) using interning to ensure that, for your custom 
> type, if two values X and Y are equal, then they will always have the 
> same userdata. At this point your userdata becomes first-class (or as 
> near as it an be in Lua) and the need for __key evaporates.
>
> (Given the noise level in this discussion, this is all I will have to 
> say on this matter.)

You'd still have to write all the metamethods. __key applies only when 
the object is being used as a key.

Also, __lt/sort doesn't apply to table keys, only values.
> —Tim

--
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.