Re: Lua 5.2 #... proposal and patch.

[Henk Boom <henk@...>]

On 6 May 2011 15:30, HyperHacker <hyperhacker@gmail.com> wrote:
> On Thu, May 5, 2011 at 04:52, Tony Finch <dot@dotat.at> wrote:
>> Benoit Germain <bnt.germain@gmail.com> wrote:
>>>
>>> So, if I understand correctly, there is one single monolithic stack of
>>> 'slots' somewhere in the VM where call frames are 'allocated', these
>>> being made of a given number of slots, the first pointing to the
>>> callinfo, and the remainder containing the parameters and locals.
>>
>> The callinfo stack is actually a second parallel stack, which holds
>> information like saved stack pointers and instruction pointers. The value
>> stack that I talked about in my previous message just contains the values
>> that you directly manipulate in your Lua program: local variables are
>> slots in this stack, as are temporary values created when evaluating
>> expressions. (FORTH systems have a similar two-stack setup. I think the
>> LuaJIT interpreter uses a single unified stack more like typical compiled
>> languages.)
>>
>>> I suppose then that the the default 20 slots we get for a C function
>>> simply belong the top call frame on this global stack, with the
>>> additional advantage of being re-sizable by the C function?
>>
>> Right. The whole stack is resizable. In pure Lua code, Lua knows how many
>> stack slots each function needs for its locals and temporaries, so it
>> checks once at the start of the function that enough space is available.
>> For C functions it just checks that LUA_MINSTACK (i.e. 20) slots are
>> available. Lua may need to resize the stack during a function if you use
>> ... (because of the unpredictable number of arguments), and similarly C
>> functions can call lua_checkstack.
>>
>> Tony.
>> --
>> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
>> Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
>> Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
>> or 6 later. Rough or very rough. Occasional rain. Moderate or good,
>> occasionally poor.
>>
>>
>
> I've always found vararg support in Lua to be awkward and confusing,
> with a lot of bugs that can crop up if one of your arguments is nil.
> Having to call select() for each argument also seems terribly
> inefficient.
> I wonder, can there not just be a table _ARG in each function,
> containing all arguments to the function? (Maybe only if it uses
> vararg?) That seems like a far simpler and less error-prone approach.
> (Though it would have to also have an 'n' field for number of
> arguments, as using # brings back a lot of those same issues when you
> have a nil argument...)

Because unlike most of the other approaches, this has the
GC/allocation overhead of creating a table.

AFAIK in lua 5.2 you can accomplish this functionality with

local _ARG = table.pack(...)

    henk