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

[Coda Highland <chighland@...>]

On Wed, Jul 3, 2013 at 12:39 PM, Eike Decker <zet23t@googlemail.com> wrote:
>
> 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
>


It's a brilliant idea, but is "nil" an alias for "nil(defined)" or
"nil(undefined)"? It'd have to be an alias for "nil(undefined)" to
avoid breaking "t[#t] = nil" and similar idioms.

/s/ Adam