Re: lists with nil play nice for Lua 5.2

[David Manura <dm.lua@...>]

John Belmonte <john <at> neggie.net> writes:
>     { f() }            -- capture function return vals which include nil

The problem with the construct { f() }, though appealing in tersity, is that it
loses information (trailing nils), at least if the number of trailing nils is
variable.  We can overcome that by save(f()), where save is defined as "function
save(...) return {n=select('#', ...), ...} end", which is correct but involves
needless memory copying.  This page was recently updated on this concern:
http://lua-users.org/wiki/StoringNilsInTables .  

A similar concern is how "x and y or z" works as a condition -except- when y is
nil. -- http://lua-users.org/wiki/TernaryOperator

The more fundamental problem I think is the restricted ability in Lua to
manipulate lists (varargs "..." and multiple return values) for functional
programming.  The typical workaround, as above, is to stuff it in a table, which
involves an extra memory allocation and leads to the above concerns, as well as
the additional concern about holes in the table, which the Lua standard library
doesn't handle.  We can avoid the table with tricks using additional function
and tail calls, but it is awkward and not necessarily efficient.  C functions
have more flexibility here because they can manipulate the stack on which these
lists are stored, but pure Lua functions don't have that kind of access. 
Ideally, we would want a way for the quite common task of manipulating stack
lists to be written in a way that is simple, efficient and correct (without
trade-off).

The "Proxy Table of Local Variables, _L" example in
http://lua-users.org/wiki/LuaHacks maybe can be adapted here to provide a table
interface, with "n" field, in C that acts as a proxy to a list on the Lua stack
(rather than as a copy into a table as I believe is the case for "arg"), but we
still have the issue with handling of holes by the Lua standard library.