Re: Bug report in length of simple table

[Dirk Laurie <dirk.laurie@...>]

2016-09-14 10:05 GMT+02:00 Jonathan Goble <jcgoble3@gmail.com>:
> On Wed, Sep 14, 2016 at 3:37 AM,  <Tomas.Lavicka@tieto.com> wrote:
>> OK, I get it. Thx 4 explanation. But can you also explain to me next behavior?
>>> table.unpack{"a",nil,"c"}
>> a       nil     c
>>> table.unpack{[1]="a",[2]=nil,[3]="c"}
>> a
>>
>> I am still confused with sequences, but I hope I will understand it soon.
>
> table.unpack works only with sequences. As the arguments here are not
> sequences, the result of the call is undefined, meaning that different
> results can sometimes be obtained from identical arguments (and those
> results may or may not be meaningful).

The issue is lower down: table.unpack uses the length operator
to get the length of the sequence. The difference in the two outputs
is caused by the different behaviour of the length operator.

<advanced>
This turn is caused is caused by the different ways in which the tables
are stored (all in the "array" part in the first case, only one element
in the "array" part in the second case). The details are quite involved
but basically #t will not change as long as you assign to indices that
exist (even if they have value nil)

$ lua
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> t={1,nil,nil,nil,nil,nil,nil,nil,nil,10}   -- indices 1 to 10 exist in the "array part"
> #t   -- there is a non-nil at the highest "array part" index
10
> t[5]=5  -- assigning to an existing index does not change #t
> #t
10
> t[12]=12  -- non-existing index triggers resizing of "array part"
> #t     -- [5], [10] and [12] are now in "hash part"
1
</advanced>