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

[Andrew Starks <andrew.starks@...>]

On Friday, July 5, 2013, Tim Hill  wrote:

Snip... 

 The language succeeds in hiding this overloading in all but one place: when an array element is assigned nil. At that point the overloading becomes apparent; nil means both "no value" and "delete", one a noun, one a verb. In EVERY other part of the language, this distinction can be ignored because the two are made equivalent by the language design: viewing a table as having an infinite number of elements, most of which are nils; the same for function arguments and return values etc.

 

Tim, I think it's pretty easy to demonstrate, in academic  and meaningful ways, how the "In EVERY other part of the language..." This is not true. Or, at least it is not transparent:

local foo = true

local bar = true

function(...)

local foo = (function() return end)()

--according to your statement, foo and bar should be true.  In a table's context they would be. But in local variable context, they are not. 

print(foo == bar) --> false 

-- also foo is in local scope, which you can't  know at this point, although unless you're debugging, who cares?

-- something that I've been bitten by, but it probably doesn't matter:

--some stuff on received arguments, last vararg is optional and if there, I want to know type:

if type(select(num_args_i_counted + 1, ...)) == "number" then 

...

--this is not safe, because type() is an error

--easy to get around and easy to understand why, just not consistent. 

My assumption, which drove my suggestion, was that nil's behavior was equivalent in tables and in locals:

nil is a sentinel that is always ignored by the garbage collector. 

So {[1]=nil}

Would never be seen by the garbage collector because nil isn't added to its list of stuff to track and 1 isn't explicitly constructed. [obj] = nil, because nil is now seen by gc as a weak object. 

If I'm saying this clearly, that behavior would also explain locals well, too. 

This behavior would, to my understanding, have avoided the need for another value and only require the need to know if something was set to nil or whether it was absent.

That seemed cheaper than a new type and simpler to add. Since that's not how things are, I think that the way it works is fine, because everything else seems to make Lua "ever so slightly bigger."

-andrew