 |
lua-l archive |
|
|
||
|
This conversation might have been shorter if somebody said:
"Tuples are a composite sequenced data type with value semantics."
Note that "value semantics" implies that the contents must also have value semantics. This limits them to numbers, strings, booleans, tuples, and possibly light userdata and nil.
Jay
> On Jul 6, 2015, at 12:20 PM, Coda Highland <chighland@gmail.com> wrote:
>
> On Mon, Jul 6, 2015 at 12:00 PM, Tim Hill <drtimhill@gmail.com> wrote:
>> At this point it’s quite trivial to write a small C
>> library that, given such a “tuple table”, would return a unique userdata
>> item (garbage collected) that was (a) the same item for any identical tuple
>> table and (b) a different item for any non-identical tuple table (where
>> “identical” means the same value at the same sequence index in the tuple
>> table, applied recursively to nested tuple tables).
>
> Why do you need userdata for this at all? This behavior is already
> present with normal tables.
>
> /s/ Adam
>
First, the tuple table may be large; you already have the overhead of the “signature”, using a dummy userdata is more compact. Second, if you mean why not index using a normal user table, then that’s not the point. The point is that when tables are used as keys, it’s the identity of the table, not the contents, which are used as the key (that’s why the table does not have to be immutable to be used as a key). The tuple table uses the tuple value itself (that is, the contents of the table) as the key, which was the need expressed by the OP (for use in memoization of function arguments).
Or, to put it another way:
t1 = {10, 20, 30}
t2 = (10, 20, 30}
print( t1 == t2 ) — false
print( totuple(t1) == totuple(t2) ) — true
The whole scheme is an elaboration of comparing the contents of two constrained (in the sense of limited domain of Lua types) sequences, but with the added ability to reduce the comparison to fast reference item equalities by surfacing the signatures as userdata (so that the signatures are garbage collected). The assumption of course is that the overhead of creating the signatures/userdata tuples is recovered by the time savings accrued when comparing tuples.
—Tim