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

[Eike Decker <zet23t@...>]

2013/7/4 Coda Highland <chighland@gmail.com>:
> On Wed, Jul 3, 2013 at 2:45 PM, Eike Decker <zet23t@googlemail.com> wrote:
>>> 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
>>
>> If you write "nil", you specify it, so it's nil(defined). The
>> undefined nil value is only created when it originated from a lack of
>> specification.
>
> Sadly I can't see any way to reconcile "nil" = "nil(defined)" with
> "t[#t] = nil" being a pop operation. It would be a
> backwards-incompatible change, and therefore can only be an opt-in
> behavior, which is of course an increase in complexity.
>
> If "nil" = "nil(undefined)" and "null" = "nil(defined)" then it works,
> at the cost of adding another keyword, but Roberto seems to indicate
> that doing so would require some additional hierarchy of values. I
> don't think I understand why.
>
> /s/ Adam

Optin could be a metatable entry that flags a table to keep defined
nil values. Then I wouldn't see a problem with compatibility. And also
not understandably wise: For ignorant newbies, it looks the same, only
a function would exist that can tell the nil's origin difference. And
the metatable entries would be advanced techniques anyway where the
subtle nil differentiation comes into play.
I still like this weird idea of having a defined/undefined nil value
that looks like a normal nil if not observed close enough... Still
can't see how it could go frenzy since the nil's origin is defined by
the code. What might look weird could be coercion operations such as
"x = x or nil" to make sure that a value is really there.

@Andrew: Having type returning more than one value is interesting.

Eike