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

Am 03.07.2013 20:46 schrieb "Roberto Ierusalimschy" <roberto@inf.puc-rio.br>:
>
> If we add a new value in Lua (call it null, empty, nothing, whatever)
> to represent null in JSON, the problem with JSON is solved, because
> we do not change JSON. This change is trivial to do, but only solves
> the JSON problem.
>
> If we add a new value in Lua (call it null, empty, nothing, whatever)
> to represent null in *Lua*, the problem is not solved. Now Lua has a new
> value, and therefore we need yet another value to represent this new
> Lua value. Adding new values will not solve the problem in Lua. Period.
>
> -- Roberto
>

Just an unfinished premature loud thought: what if nil is a type with different states similar to Boolean that can be true or false? Maybe this is a very stupid idea but I want to elaborate on it a bit...

Setup:
The states could be nil(defined)/nil(undefined). Both values are very special:
nil(defined) == nil(undefined) -- yes, this results in "true"
a,b = nil -- a is nil(defined), b is nil(undefined)

Actually, both nil states are indistinguishable on a syntax level - the distinguishing can only happen through a special function that can tell the difference, nothing else can. This somewhat similar to the SQL concept where null is checked by doing "is null" and not "= null", which is false (if I recall correctly).

Consequences:
I think the result of this logic could be disastrous.... But maybe this crazy logic still makes sense:

a,b = nil
function f(a,b,c)
-- if called this way: f(a,b), a is nil(defined), b and c are nil(undefined)
-- if called this way: f(a,b or nil), a and b are nil(defined), c is nil(undefined)
end

Interesting is also the case for tables: if a value is nil(defined), it continues to be present in the table and the slot is NOT removed. Thus:

function delete() end -- returns nil(undefined)
t = { a=1, b=nil, c=delete()}
t.a = delete()
-- status: t.b is nil(defined), t.a and t.c are nil(undefined) and thus do not exist

Consequently, popping an array element works by doing "t[#t] = delete()" or "_,t[#t] = nil" - which is interestingly quite close to my last suggestion of storing nil values in tables. Also interesting is, that arrays remain arrays as long defined nil values are present and forming a sequence. Also, it can be distinguished between functions that return a value or no value - or if the number of returned values is invalid (somehow, this is where debugging becomes interesting).

The concept is maybe very wacky, but somehow, it's intriguing me ... What I strongly dislike is, that it's difficult to explain to beginners and also hard to understand maybe. On the contrary, the current nil concept and the deletion of array elements is also lacking.

From my point of view, this would be almost completely compatible with existing code, except that table element deletion needs to be revisited (we had this discussion in the other thread).

Well, as crazy as this idea might be, I hope have given you something interesting/fun to think on :)

Cheers,

Eike