Re: Empty? No. Array? No. Has? Yes.

[Dirk Laurie <dirk.laurie@...>]

2013/7/7 Andrew Starks <andrew.starks@trms.com>:

> So, yes names are slots and anything can be in them. But it simply
> isn't true that "not ever there" and "nil" are the same thing.

On the VM stack, that is true and the proof is in the User's Manual.
Three functions in the C API.

int lua_isnil (lua_State *L, int index);
   Returns 1 if the value at the given index is nil, and 0 otherwise.
int lua_isnone (lua_State *L, int index);
   Returns 1 if the given index is not valid, and 0 otherwise.
int lua_isnoneornil (lua_State *L, int index);
   Returns 1 if the given index is not valid or if the value at this
   index is nil, and 0 otherwise.

At the level of the scripting language, you have `select("#")` that
allows the distinction.

At the level of table entries, the difference is in the implementation
of a table: the "array part" (in which nil is there) and "hash part"
(in which is isn't). However, the programmer, even the C API programmer,
is not allowed access to that distinction. Lua reserves the right to
split it pleases. You can suggest, but no more.  The User's Manual again:

void lua_createtable (lua_State *L, int narr, int nrec);
   Creates a new empty table and pushes it onto the stack. Parameter narr
   is a hint for how many elements the table will have as a sequence;
   parameter nrec is a hint for how many other elements the table will
   have. Lua may use these hints to preallocate memory for the new table.

Therefore, if you need a solid, storable value not equal to any other
value in the table, it must have its own reserved name and value. In
the case of an array, keeping track of an explicit highest index is a
workaround that allows you to do without such a value.

Up to here, I agree with Tim. Where we disagree, is that:

   Tim thinks:
   -  the need for such a value is sufficiently common and uniform to
      justify adding a name and value to the Lua language itself;
   -  using one of the well-known idioms to create a unique value for
      a particular Lua instance is an inadequate workaround.

   Dirk thinks:
   -  the reason why one needs it is application-specific (SQL NULL,
      reserved-but-unused, etc);
   -  reserving a name by consensus among people that need it is good
      enough.

You're welcome to add an "Andrew thinks" entry to this list.