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

[HyperHacker <hyperhacker@...>]

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...)

-- 
Sent from my toaster.