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

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

On Wed, Jul 3, 2013 at 2:32 PM, Philipp Janda <siffiejoe@gmx.net> wrote:

> This makes assignments (or argument passing, or table construction) more
> predictable:
>
>     local a, b, c = empty(), multi(), 3

However, I think that empty() lack of a return value need not be
promoted to 'nil'

Either way is explainable, however. One could say, "If a value is not
defined in a multi-assignment, it is promoted to nil, unless it is the
last value."

This is symmetrical with multi-returns being reduced to one value, as
you've demonstrated.
>
> c is 3, no matter what empty() or multi() return. IMHO this would be even
> more important if table access become vararg expression lists:
>
>     local a, b, c = t[ 1 ], t[ 2 ], t[ 3 ]
>
> c should be equal to t[ 3 ] even if t[ 1 ] and t[ 2 ] do not exist.

Of course, but it would seem reasonable that:

exists(a) --> false
exists(b) --> false
exists(c) --> true
print(c == t[3]) --> true

could also happen. No?
>
>
>>
>>      select( '#', baz, baz, baz, foo ) --> 4
>>>
>>>      { 1, baz, 2, baz }        --> { 1, nil, 2 }
>>
>>
>>
>> In the case of table access, I'd suggest that "nil" would be the default
>> return for all values, but that you could still call an exists-like
>> function on any index value.
>>
>> select(1,({1,baz,2,nil})[2]) --> 0
>> select(1,({1,baz,2,nil})[4]) --> 1
>
>
> So this would be an exception to the usual argument adjustment: If inside a
> table constructor, do not adjust an empty list to a single nil, only
> increment the index.

I think that non-existant table keys return "nil" as a value, by
default. This could be true, generally, as well, which would not be
what was contemplated, above.

that is, this concept coexists well with the following behavior:

local foo
print(baz) -->nil
print(foo) -->nil
print(exists(baz)) -->false

t = {foo, baz, 3}

print(exists(t[1]),exists(t[2]), exists(t[3])) -->true, false, true

---
I don't see any wierdness to that...

>
> I'm not sure this is worth it.

Do you see inconsistencies with the possibility that an argument
position would be undefined? Lua could always substitute "nil" in such
cases, but at least there would be a way to find out.
>
> I'm sorry, I'm using:
>
>     function exists( ... )
>       return select('#', ... ) ~= 0
>     end
>
> which is why I didn't catch the precedence bug in your version (as Matt did
> else-thread).

Right. Sorry about that. The large point is that:

function exists( ... )
      return select('#', ... ) ~= 0
    end
local foo
a = function() return end
print(exists(a())~=exists(baz))
--> true

...makes me sad.

-Andrew