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

[HyperHacker <hyperhacker@...>]

On Fri, May 6, 2011 at 13:38, Henk Boom <henk@henk.ca> wrote:
> 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
>
>

Does it have to be a real table though? Could it not be a special case
using the same logic as ... internally (and maybe just throwing an
error or automatically converting to a real table if you try to treat
it like a table outside of simple accesses)? I think a bit of "magic"
is acceptable for variables following that naming convention; see _G
and _ENV already having some "magic" of their own.

-- 
Sent from my toaster.