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

[David Kastrup <dak@...>]

Pierre-Yves Gérardy <pygy79@gmail.com> writes:

> On Wed, Dec 15, 2010 at 08:31, Dirk Laurie <dpl@sun.ac.za> wrote:
>
>     -- 'nil' makes no distinction between 'unknown' and 'non-existent'
>     .
>
>
> Besides `nil` which represents nothingness explicitly, Lua also has an
> implicit nothing. Try print(nil) versus print(print()), for example.
> In this context, functions with no return value evaluate to nothing at
> all, not even nil.

You are confused about the difference of returning a nil value (namely a
value list containing a single entry of value nil), and of returning a
nil value list (namely a value list containing no entries).

> There's no warranty that `print( tostring( foo() ) .. "bar" )` will
> work all the time. You must use `tostring(( foo() ))` to be safe.

Value coercion will give you one value from multiple values, and one
value from zero values.

> Surprisingly, some (most?) functions in the standard lib don't behave
> as if an empty arg list was nil...

An empty arg list _is_ nil.  The functions distinguish between a nil
arglist, and one containing nil as an element.

> I'll add this to the Gotchas thread as well, because, it puzzled me at
> first, and although I now understand how it works technically, it is
> still a leak in the language abstraction.

I don't see how.  The only "gotcha" involved here is that {...} is not a
faithful representation of an arglist since it does not capture the
number of arguments, as trailing nils are significant in arglists,
insignificant in tables.

-- 
David Kastrup