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

[Benoit Germain <bnt.germain@...>]

2011/5/4 Tony Finch <dot@dotat.at>:
> Benoit Germain <bnt.germain@gmail.com> wrote:
>>
>> From what I've seen of the implementation (which is little), when a
>> function is vararg, the call frame info has an array somewhere that is
>> dynamically allocated and populated from values gotten from the VM
>> stack when it is called. Then, when '...' is referenced in the
>> function body, OP_VARARG copies some or all elements from this array
>> into the call frame's stack.
>
> Not quite.

Well, if I remove "dynamically allocated" and the additional cost
inepsy from what I said, I wasn't too far off after all :-).

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. 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?
Thanks for the detailed explanation, I'll die knowing one more thing :-)

> I think that it might be nice if tuples in Lua were just sequences of
> values on the stack. The problem dealing with variable size tuples is that
> Lua relies a lot on static knowledge of the stack layout - which is why
> the named arguments get copied when you call a variadic function.

Yup. Being able to name the tuple received as a function argument and
being able to declare tuples at will in a function are two different
things. Lua functions, as opposed to C functions, don't grow their
stack, because
when all locals use up exactly one stack slot it is 'easy' for the
compiler to compute the max number of slots necessary for a given
function. Which isn't necessarily to say that something prevents them
to do so, since C functions can.

Declaring a tuple would then have to work like what happens when
growing the stack in a C function: the compiler would still reserve a
stack slot in the call frame for the tuple variable, but this slot
would not store the value itself like a regular variable does. In
other words, a tuple is a new data type. It would be used to store the
range of slots that the VM dynamically assigned by expanding the call
frame to accommodate it for the required amount of slots. This would
work fine even when having more than one tuple in a function, as long
as a tuple isn't re-sizable, else this would *really* get complicated.

So, to sum up, all this becomes a big "add in the language the ability
for a Lua function to grow its stack just like a C function does".
This sounds like an irresistibly appealing change that offers
possibilities way beyond the simple solving of "give easy access to
the contents of ... without having to go through a C function". In
other words, it is the spirit of Lua :-).
However, implementing this doesn't sound like a minor undertaking to me...

And once we have tuples, we have immediate access to their slots. And
the length of a tuple is defined as the number of slots it is made of.
Problem solved :-).

-- 
Benoit.