Re: lua-5.1-alpha: length operator on tables (arrays) and nil

["Rici Lake" <lua@...>]

Wim Couwenberg said:
>> I don't see why
>> ... is better than arg. It introduces inconsistencies, new compound
>> structures, etc. with no immediately obvious advantages. What's so good
>> about the change?
>
> A function invocation in 5.0.2 with 5 parameters of
>
>      function f(...)
>        -- use arg table here
>      end
>
> is between 5 to 6 times slower than the same invocation in 5.1 of
>
>      local select = select
>
>      function f(...)
>        local n = select("#", ...)
>        -- use ... and n here
>      end
>
> So, that seems to be good about this change...  :-)

True. On the other hand, using (functional) tuples to create a named local
from ... (similar to the pre-5.1 model, but with tuples instead of tables)
turns out to be almost three times as fast, and is considerably more
powerful, since the local can be used as a first-class value (for example,
as an upvalue).

Tuples (or at least this kind of tuple) differ from tables in a couple of
important ways: first, they are immutable; second, they have a
well-defined length (including nils :) ); and third, they could support a
concatenation operation, which is hard to define for tables. Furthermore,
Lua already has an immutable tuple of precisely this nature; however, it
has a restricted range (characters). So tuples (implemented as functions):
(1) do not fundamentally introduce a new datatype; (2) generalise an
existing datatype;  (3) have a number of uses other than capturing
varargs; and (4) manage to capture varargs reasonably rapidly. (I suspect
that Mike Pall could even manage to avoid the allocation with LuaJIT in
the cases where there is actually no need to perform the allocation.)

I do realise that this decision has been made, and that I've said this all
before. So feel free to ignore the posting.

Rici