lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


To followup [1], can someone remind me what is the rationale for Lua
5.1 tables not storing an explicit table length, which thereby
prevents trailing nils from being regularly counted in the table
length?  I'm not suggesting storing length in a regular table key,
like the Lua 5.0 "n" field which affects things like pairs iteration,
but rather storing it in some hidden location accessible only via the
# operator.

My second comment is that Patrick mentioned something that made me
think why not support the following:

  function f(...)
    for i=1,#_ARG do print(_ARG[i]) end
    g(...)  -- or g(unpack(_ARG)) or maybe g(_ARG[*])
  end

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.

[1] http://lua-users.org/lists/lua-l/2010-05/msg00587.html