Re: explicitly defining table length + _ARG proposal

[Roberto Ierusalimschy <roberto@...>]

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

-- Roberto