Re: In praise of 'nil' (Was: Proposal for table length operator

[Pierre-Yves Gérardy <pygy79@...>]

On Wed, Dec 15, 2010 at 10:02, David Kastrup <dak@gnu.org> wrote:
> An empty arg list _is_ nil.

I beg to differ. An empty explist is just an empty explist.

    select("#",nil) --> nothing
    function foo (...) return select( "#", ... ) end
    foo() --> 0

> The functions distinguish between a nil
> arglist, and one containing nil as an element.

Then, per your above definition, nil ~= nil.

The behavior of the empty explist isn't explicitly documented.

>From http://www.lua.org/manual/5.1/manual.html#2.5 :
|> Both function calls and vararg expressions can result in multiple
|> values. If an expression is used as a statement (only possible for
|> function calls (see §2.4.6)), then its return list is adjusted to zero
|> elements, thus discarding all returned values. If an expression is
|> used as the last (or the only) element of a list of expressions, then
|> no adjustment is made (unless the call is enclosed in parentheses).
|> **In all other contexts, Lua adjusts the result list to _one element_,
|> discarding all values except the first one**.

Side note:

tostring() is implemented as

    function tostring(...)
        assert( select( "#", ... ) > 0, "bad argument #1 to 'tostring'
(value expected)" )
        return stringify( select( 1, ... ) )
    end

While this makes completely sense when seen from the C side, in the
Lua world, it is not intuitive at all. Emulating the following
behavior would make more sense IMO, especially since it is documented
as such in the reference manual.
http://www.lua.org/work/doc/manual.html#pdf-tostring

    function tostring (str)
        return stringify( str )
    end

It is reasonable to expect that a core function like tostring will not
crash when fed with basic Lua code (if a __tostring metamethod is
defined, it is another story, of course).

--Pierre-Yves