Re: [ANN] Lua 5.2.0 (work1) now available

[Robert Raschke <rtrlists@...>]

On Fri, Jan 15, 2010 at 4:10 PM, T T <t34www@googlemail.com> wrote:

2010/1/15 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:

>> Agreed. The only reason #t has its undefined behavior is because it is
>> impractical for it to iterate the table.
>
> I disagree. In my point of view, there is no sensible semantics for #t
> when the table has holes.
>
> Consider the "lists" below and think what should be their length:
>
>  {1, 1, nil, 1, 1, 1, 1, 1, 1, 1, 1}
>  {1, 1, nil, 1}
>  {1, 1, nil, 1, nil}
>  {nil, nil, nil}
>  {[100000] = 1}

>From a programmer point of view, #t defined as max(k) for k>=1 and
t[k]~=nil (or 0 if no such k exists) makes the most sense to me. This
definition is unambiguous, doesn't depend on the pattern of
insertions/deletions to/from a table and is what you normally want to
know (i.e. how big is the continuous block of array elements you can
iterate on). Sparse arrays (arrays with holes) need to be handled with
pairs anyway in order to catch all the keys.

That would mean #{[100000] = 1} == 100000 . How is this the size of "the continuous block of array elements you can iterate on"?

This definition divorces the meaning of # from the meaning of "size".

Robby