RE: nil isn't as unique in Lua 4.1

["Eric Ries" <eries@...>]

Agreed. Both proposals (esp. #2) strike me as superior to introducing a new
special value "false" to go with the special value "nil"

Eric

> -----Original Message-----
> From: owner-lua-l@tecgraf.puc-rio.br
> [mailto:owner-lua-l@tecgraf.puc-rio.br]On Behalf Of David Jeske
> Sent: Friday, January 11, 2002 12:30 PM
> To: Multiple recipients of list
> Subject: Re: nil isn't as unique in Lua 4.1
>
>
> 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
>