Re: Non-copying varargs (Was: Re: inadequate documentation for select and table.unpack)

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

2016-06-20 23:27 GMT+02:00 Soni L. <fakedme@gmail.com>:
>
>
> On 20/06/16 05:02 PM, Dirk Laurie wrote:
>>
>> 2016-06-20 21:04 GMT+02:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
>>>>
>>>> A point that does rate some extra explanation, but perhaps iin PiL
>>>> rather than the reference manual, is that 'select' is in fact an
>>>> extremely efficient operation, involving no actual copying of
>>>> arguments. There is no API equivalent, because none is needed.
>>>> It returns the stack exactly as it found it, but reporting a possibly
>>>> different number of return values.
>>>
>>> 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.
>>
>> Could you explain why that happens? luaB_select is clearly O(1).
>> Does VARARG copy the arguments? If so, why is that necessary?
>
> It's not strictly necessary, but the solution involves a linked list and
> copy-on-write.
>
> If not handled right, debug.setlocal would affect multiple varargs lists
> instead of just one

So the only track debris blocking the racing-car is the Lua counterpart
to BASIC's POKE?

O(n) instead of O(1), on a function so essential that it is not even
wrapped in a sublibrary but supplied directly in _G, seems to be
a large price to pay for a specialized tool that we are enjoined to
"exert with care when using".

Can't we rather have fast VARARG plus a warning in debug.setlocal
that its use on functions that have '...' is even more perilous than the
rest of the debug library?
...
> Thus, while I'd greatly benefit from non-copying varargs (I even thought
> about proposing this once), it would be a maintenance nightmare for the Lua
> team.
>
> And I didn't even mention the interaction between this specific varargs
> implementation and multiple returns...

It seems that even select('#',...) generates VARARG.

VARARGGGGHHHH!