Re: pairs(t, skey) and ipairs(t, skey)

[Javier Guerra Giraldez <javier@...>]

On Wed, Oct 2, 2013 at 11:55 AM, Paul K <paulclinger@yahoo.com> wrote:
> I think the "sequence" in #t operator description is misleading (or at
> least needs to be supported with some examples and gotchas): (1) #t
> can be less than t->sizearray if there are holes in the array part,
> but it's not guaranteed to stop at the first hole as it does binary
> search simply looking for n ~= nil and n+1 == nil, and (2) #t can be
> more than t->sizearray when t->sizearray == 0 and there are happen to
> be numeric keys in the hash part that form a sequence starting from 1.


I think the confussion arises because many of us are used to think
that Lua tables store all 'sequence-like' values in the array part.

but.... that 'array part' is just an optimization.  it should be
totally transparent, and everything (including the #t quirks) should
be exactly the same if the Lua used pure hash tables and there wasn't
any array part.

so, i guess it's very hard, an likely impossible, but it is
conceivable that a valid sequence table has all its values in the hash
part.  in that extreme case, #t should still work, but next() would
report all keys in random order.

that puts some attention on one part we seldom discuss: how and when
does the Lua table implementation maintains the array part?  I seem to
remember Roberto (or Luiz?) writing that "the array part grows and
shrinks to keep it more than half empty", or some similar
specification.

-- 
Javier