Re: nil isn't as unique in Lua 4.1

[David Jeske <jeske@...>]

On Fri, Jan 11, 2002 at 12:30:05PM -0500, RLake@oxfam.org.uk wrote:
> I dunno. I came up with one way of dealing with it, and it works
> pretty generally. I hide the mechanics in tag methods, so the code
> really does what it looks like its doing (as with other stuff hidden
> in tag methods). I really don't find that I have to work around the
> problem much, to be honest.

The idea of changing every if statement to include tests for some new
"false" table does not feel like a solution to me. That's basically
what I do now with != 0. Also, tag method tricks which negatively
impact the performance of looking up values in tables also do not feel
like solutions.

> I think that in at least two of the examples you gave, you did not
> actually want to distinguish between nil and false.

This really isn't to distinguish between nil and false, it's to be
able to store a 'logically false' value in a table, for one of many
reasons.

For those who don't like introducing boolean values, there are at
least two other solutions to this problem.

1) One way to look at it is that it's this 'unstorable nil' which is a
problem. Afterall, the C interface can tell the difference between a
missing paramater and LUA_T_NIL in a variable argument list, why can't
lua?

One could solve the storable nil problem by removing the semantic that
a["foo"] = nil, deletes the table value, and instead introduce a 'del
a["foo"]' operation. Then there would be a new existance test, such as
Python's a.has_key("foo"), or something similar.

2) Another way to look at it is that the boolean tag methods are
missing. There are tag methods for "add","sub","mul", and "div", but
why not "and", "or", and "not"? If there existed, then those of us who
need a false value could just make a special table and put in new tag
methods to honor that table as a false value. 

--

Personally, I think that either introducing a false value, or (#2)
above, introducing boolean tag methods both solve the problem pretty
well.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net