Issues with the current varargs implementation (Was: Re: inadequate documentation for select and table.unpack)

["Soni L." <fakedme@...>]

On 21/06/16 09:09 AM, Viacheslav Usov wrote:
> On Mon, Jun 20, 2016 at 9:04 PM, Roberto Ierusalimschy 
> <roberto@inf.puc-rio.br <mailto:roberto@inf.puc-rio.br>> wrote:
>
> > That is not true. 'select' can be quite slow for a large number of 
> parameters (where "large" starts in the order of a few dozen). In 
> particular, a typical loop in a vararg function using 'select' is 
> quadratic with the number of arguments, while creating a table and 
> traversing it is linear.
>
> That could be why the manual and PiL are a little shy about this function.
>
> Yet, this discussion has revealed that even those familiar with select 
> have very wrong ideas about it. It looks like there is no really 
> lightweight mechanism in the language to access an arbitrary variable 
> in a variadic function. It may be that Lua could benefit from some new 
> syntax for that.
>
> Another possibility could be in making {...} very lightweight. That 
> syntax could create a new internal type that is essentially just a 
> maker; and in all the cases when such a value can potentially be 
> leaked from the current function, it gets replaced with a real table. 
> I should say that I am not sufficiently familiar with Lua's internals, 
> so this could be a ridiculous thing to propose :)
>
> Cheers,
> V.
Varargs aren't lightweight. Inserting new varargs requires copying the 
whole varargs array, even for tail calls (however, this could be 
trivially optimized, at least in theory, by treating varargs as a proper 
stack and using the realloc-able end as the first position).

They could be made somewhat lighter by using a linked list of sorts, see 
[1], but that comes with its own set of drawbacks.

[1]: http://lua-users.org/lists/lua-l/2016-06/msg00189.html

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.