Re: new "empty" value/type in Lua?

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

On Jul 1, 2013, at 17:37, Tim Hill <drtimhill@gmail.com> wrote:

> Agreed, and you suggest an interesting approach. Is the end-game of this an array that is (in effect), of a declared size? In this model, that is just what # returns all the time, and you can do all you like with nils and use whatever integer indexes you like (less than or greater than #), but not alter #. Of course, at that point # is just a fancy way of the old-style "n" field and thus has deteriorated to not being much use. Not sure I like this much.
>
> The flip side here is subtle changes to the behavior of "nil", a more complex table API, and some boundary cases that might be a bit messy, but I agree that avoiding the introduction of a new type is worthy.

I'm way back here... Sorry.

On thinking of this more, it seems like an array library may solve the
original problem. However, Eike's solution for a delete and has method
seems to solve a much deeper issue:

assert(_ENV.print, "print is in the scope's up value.")

local print --without my computer, I'm not absolutely positive what
this does. I'm 99.99 percent chance sure that it's now nil in the
current scope  and 100% sure it's still somewhere as an upvalue.

assert(foo == nil)

local foo = nil -- or just local foo

do
  foo = "value"
end

-- okay, foo is an upvalue of the block and is now a string, but
-- explaining it, given what we know about setting a table value to
nil, seems like an exception to otherwise consistent behavior.

--worst of all
type(nil) --> "nil"
type() --> error!

-----
So, what I think best describes the current situation is that:

1: nil plays the roll of empty, as proposed by Tim, better than it
does at playing the role of "not there".
2: there is no way consistent way to access information about what
isn't there and what is there but nil, aka "empty"

I brought this up long ago and so I apologize for bringing it up
again, but perhaps there should be an `exists` function, which returns
true if the value has been declared and false if not. A `delete`
function would serve to actually remove a value.

I believe that this is the essence of Eiki's solution, except that I
perhaps it should not be limited to table values, but also work the
same for locals.

-----
local foo

exists(foo) --> true
exists(_ENV.foo) --> false

delete(foo)
exists(foo) --> false

holy_array[10] = nil

exists(holy_array[10]) --> true

exists(holy_array[1000]) --> false (pretending the array ended at n < 1000

------

Given the above behavior, it may be correctly stated that __index
defaults to returning `nil` on empty values.

I think I'm just renaming and verbosely restating what Eike proposed
and what was discussed. My apologies.

My point is that an array library would be nice and would provide for
a nice place to monkey patch other functionality (map, slice, ...).

I believe that exists and delete would make Lua clearer and remove a
slight bit of inaccessible magic.

-Andrew Starks

"As we get older, and stop making sense"
-David Byrne