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

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

2011/5/4 GrayFace <sergroj@mail.ru>
>
> Now, this can be expanded further:
>
> function f2()
>  local r... = pcall(f1)
>  if not r[1] then
>    print("error: "..r[2])
>  end
>  return r...
> end
>

>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. This means several things:
- the content of '...' lives outside the VM's stack, and is not
accessible by user code until values are copied in the stack or in a
global (in Lua, by an affectation statement, or in C when a function
receives '...' as a parameter).
- compared to a regular function, calling a vararg function incurs an
additional cost to manage this array of extra values (memory
management). I haven't checked if this array is kept around or
allocated/freed each time we enter/leave the call frame.
- if one were to be able to declare and use tuples everywhere, I
suppose the same kind of management would have to be done. From the
Lua side I find your suggestion appealing. From the VM side, I think
that this won't be doable without creating a new data type which would
very much look like a table with only the array part, a few opcodes,
and new API calls. It's not for me to say if it will ever happen or
not, but I wouldn't expect it anytime soon :-) (Lua 6?)


--
Benoit.