Re: explicitly defining table length + _ARG proposal

[Patrick Donnelly <batrick@...>]

On Tue, Jun 22, 2010 at 12:24 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> [...]
>> where _ARG is a specially defined variable lexical to the current
>> function with `...` params and containing the values in `...`.  It is
>> "specially defined" in the manner of self and _ENV.  It is therefore
>> not too unlike the `arg` variable in Lua 5.0 except for a couple
>> differences.  Formally, _ARG is a userdata or table with __index and
>> __len operators that serve the purpose of `select` and with the __len
>> operator including trailing nils in its count.  _ARG may also be
>> mutable, allowing things like `_ARG[i] = _ARG[i] or 0`.  Finally,
>> there is an important performance optimization: if the function does
>> not do things like store `_ARG` in another variable, pass it to
>> another function, add keys to it, or use it as an upvalue, then `_ARG`
>> can be optimized away by the compiler and doesn't actually need to be
>> constructed in memory: #_ARG and _ARGV[i] merely render as opcodes in
>> the VM.
>
> If Lua was able to do that kind of optimizations, it would not need
> _ARG. We would be better served by the old-style 'arg' parameter
> optimized away when possible.
>
> There is no free lunch. All 1st-class objects with a minimum of
> structure in Lua (strings, closures, tables) are allocated on the heap,
> a standard technique in several languages (Java, Scheme, etc.).  To
> avoid this, either the language or the compiler (or both) becomes much
> more complex. So, either '...' is heap allocated (which defeats its
> purpose) or it is a 2nd-class citizen.
>
> To treat it differently in some operations (e.g., #...) may help
> programmers, but will only make it even more 2nd class (that is,
> different from all other values).

Right, so we need (as I see it) either to make ... a first class value
(maybe something like an upvalue so it is on the stack for most uses)
or we need to add a new syntax to access an arbitrary value in ... and
a way to get the length. I think most everyone agrees select() is a
performance detriment and inelegant. It'd be nice if we could get rid
of it.

-- 
- Patrick Donnelly