Empty? No. Array? No. Has? Yes.

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

My own opinion on the matters arising from 'empty' is already contained
in the Subject field of the post. The rest of this post is a summary of
the century-scoring thread.

---------------------------------------------------------------------

Non-constructive parts of the debate:

   1. We've heard all this before.
   2. I prefer to ignore most if not all of your post so that I can get
      in a reply as fast as I can type.
   3. You're not really listening to me. Here is the same stuff again.
   4. This list sucks, I'm leaving.

The problem:

   There are many situations where the programmer, especially the
   newbie programmer, has a reasonable right to expect Lua to be able
   to tell whether a key with no useful value is just a nonsense key
   (probably a typo) or a key that forms part of the logical design
   but has no value just yet.

Example cases:

   Arrays acted on by the table library; database-like tables with
   missing fields.

The non-solution:

   `nil`, though explicitly stored by Lua on the VM stack or inside the
   array part of a table, is also used to indicate a value when there
   is none, and hence does not carry enough information for making that
   decision.

Workarounds:

   Sentinels (i.e. unique Lua objects) to take the place of nils;
   exploiting the __index, __newindex, __pairs, __ipairs and __len
   fields of the metatable.

Criticism of the workarounds:

   The wheel is being reinvented in slightly different ways all the
   time when the underlying problem is still the same.

Suggested extensions to Lua:

   1. A standard sentinel value (called 'empty', 'placeholder' etc)
      maybe even having its own type.
   2. A dedicated implementation of arrays, maybe as a new type, maybe
      as a new library, maybe dependent on non-numeric fields.
   3. New standard functions: 'table.has' to indicate whether a key is
      legal; 'table.delete' to permanently change the legality status
      of a key.

Non-negotiable restriction on any change:

   Full backward compatibility, including validity of the idiom
   t[#t]=nil for shortening a list.

My own suggestion, totally ignored so far:

   Implement 'has' via a new metatable field, whose behaviour depends
   on its type.

   - nil or none: the current behaviour
   - nonnegative integer: value of #tbl, positive numeric keys being
     legal only if in the range 1..#tbl
   - table: a prototype containing legal keys
   - function: a decision procedure for establishing legality

-----------------------------------------------------------------------

The next few points are comments rather than points already made.

1. Any solution that addresses only arrays does not solve the problem
   identified by the OP.

2. It's a pity there were not more posts along the lines of:

   - This is what we do in our organization.
   - This is how long we've been doing it.
   - This is how our programmers react to our way of doing it.
   - This is the way we implement it.