nil

[RLake@...]

OK, I give up. At least it served to create some debate.

I think that David's first suggestion (that is, undefine is not the same is
assigning to nil) is a better solution. I cannot see an efficient way of
implementing short-circuiting boolean tag methods and I, for one, am not
willing to give up on short-circuiting "and" and "or". Frankly, I think
that an isfalse tag method is a much cleaner solution, but that requires
the ? operator which no-one seems to like. (On the other hand, it does not
require the "ond" operator, which is not very pleasant either.)

If it's possible to insert nil into a table, then it is necessary to be
able to disambiguate (occasionally) between a table reference whose value
is "nil" and a table reference whose key is not in the table. Since the
value might be nil, it is not possible for an operator which tests for
existence to return the value; it must be a strictly boolean operator
returning true or false. I can live with that, although it seems to me that
there are more compact ways of writing expressions.

My (possibly) final word on the debate is that everyone can think up
reasons for a specific boolean implementation, but the reality is that it's
a troolean world (at least), and every example has a counter-example. For
example, David is quite right about his applications which want to iterate
over all keys, including the ones which happen to have nil values
associated with them. However, doing that will not work for a normal
implementation of a set, in which you want to iterate only over keys which
have true values associated with them. I use a lot of directed graphs, for
example, which I represent as double-indexed tables; the interior table has
the weight of the edge. So it's convenient to be able to write rel[i][j] =
foo(...) and let foo return nil to indicate that there is no relationship.
(I use an automagicking tagmethod to prevent the obvious problem with this
idiom, by the way.) Several people have wanted to distinguish between an
explicit nil argument and an omitted argument, but it is easy to come up
with situations in which this produces exactly the wrong answer. And so on.

It is actually the case described above which I find particularly annoying
in the change of comparators to returning false instead of returning nil,
and I don't think that this has ever been put on the list of
incompatibilities between 4.0 and 4.1. Essentially, it means that I have to
replace things like:
   rel[i][j] = distance(i, j)
with
   do local t = distance(i, j)
     if t then rel[i][j] = t end
   end

That's not a big change, but it's a change and I do not believe that the
original expression was in any way "improper" or hard to read. (If
anything, it's easier to read than the new expression.)

But like I say, every example has it's counterexample.

So I'll shut up on the subject now.

Rici