Re: Tuples and other constant values

[Coda Highland <chighland@...>]

On Wed, Jul 8, 2015 at 3:13 PM, William Ahern
<william@25thandclement.com> wrote:
> On Wed, Jul 08, 2015 at 11:36:47PM +0200, Philipp Janda wrote:
>> Am 08.07.2015 um 19:52 schröbte Andrew Starks:
>> >
>> >Lua strings are tuples, correct?
>> >
>>
>> I'd say: Tuples are to tables what strings are to userdata.
>>
>> Have you ever wondered why strings aren't implemented as userdata (given
>> Lua's minimalistic nature)? Both are essentially sequences of bytes, after
>> all.
>>
>
> By using the term, tuple, in such an abstract manner it basically loses all
> practical meaning. Everything is a tuple. Numeric values are treated just
> like string values in Lua, too. Numeric values are 1-tuples. Strings (both
> in the abstract and in the Lua implementation) are either n-tuples or
> 1-tuples, depending on context. Userdata are 1-tuples just like numbers,
> with the only difference being that the values come from a different domain.
>
> What are we to make of these equivalencies, though?
>
> Ultimately the OP simply wanted to be able to index a data structure using a
> user defined n-tuple key. So far I've only heard two suggestions: 1)
> radically change the typing semantics of Lua with constant tables, or 2)
> implement the abstract interface using nested tables and a function
> accessor.
>
> At the altitude this discussion is taking place, neither approach is
> distinguishable.
>
> In the same spirit as Lua's method calling syntax, what about 3) simply
> converting
>
>         local v = t[a,b,c]
>
> to
>
>         local v = t[a][b][c]
>
> where the compiler inserts the necessary checks for nil tables. Similarly
>
>         t[a,b,c] = v
>
> becomes
>
>         t[a][b][c] = v
>
> where the compiler autovivifies the intermediate tables, just like in Perl.
> This syntactic sugar would only be useful as a practical matter where the
> number of elements in the tuple-key is fixed, otherwise disambiguiting
> intermediate tables from the value being queried would introduce unnecessary
> complexity in the language and/or the VM. But in some sense that's almost
> preferable, the constraint being akin to strict typing.
>
> Alternatively, 4) Lua could add a new metamethod, __hash, and then use
> __hash and __eq when indexing another table. Perhaps to maintain performance
> in the common case, like __gc these methods are only used if defined at the
> moment setmetatable is invoked.
>
> For my money I would simply choose suggestion #2.
>

One of the options you haven't included is to make tuples an interned
data type like strings, such that identical tuples have reference
identity. This makes using a tuple as a table key require no extra
implementation. As both Cosmin and I have demonstrated, this can
actually be done completely in Lua code (or using the C API) without
need of help from the core. If we call the userspace interning
approach #5 and the in-core interning approach #6, my preference is
roughly 5 > 2 > 6 > 3 ~ 4 > 1.

Of note is that these are essentially ranked first in descending order
of invasiveness into the Lua core, then in descending order of
syntactical impact on user code (hence preferring something that looks
like table indexing over something that looks like a function call).

That said, I wouldn't mind syntactical sugar to allow multiple values
passed to [] to be converted to a tuple (i.e. t[a,b,c] ==
t[tuple(a,b,c)] == t[unpack({a,b,c})]). This would work best with #6.

P.S. #3 has some pretty glaring inefficiencies when the low-order
elements of the tuple have a lot of distinct values.

/s/ Adam