Re: Empty? No. Array? No. Has? Yes.
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Empty? No. Array? No. Has? Yes.
- From: Philipp Janda <siffiejoe@...>
- Date: 2013年7月04日 03:23:00 +0200
Am 03.07.2013 22:10 schröbte Andrew Starks:
On Wed, Jul 3, 2013 at 2:32 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
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
No, the local statement defines the variables a, b, and c, and t[1] and
t[2] are adjusted to a single value. So exists(a) and exists(b) should
also return true, even if exists(t[1]) and exists(t[2]) are 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.
The idea was that nonexistent table keys return nothing which in most
cases would be adjusted to a single nil value, unless the field access
happens at the end of a list (RHS of an assignment, argument list, or
table constructor) ...
that is, this concept coexists well with the following behavior:
local foo
print(baz) -->nil
This would actually print just an empty line. print is a vararg
function, and the undefined baz is at the end of the argument list, so
no adjustment takes place ...
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.
My objection is that we have multiple cases, where an expression that
evaluates to zero values is adjusted to a single nil value:
- RHS of an assignment (not last element): `local x, y = empty(), nil`
- argument list (not last element): `print( empty(), nil )`
- table constructor `t = { empty(), empty(), 3 }`
- operand of arithmetic expressions: `empty() + 1`
- indexing operand: `empty().x = 1`
- explicit parentheses: `(empty())`
- etc.
So if we want `{ empty(), empty(), 3 }` to end up as `{ <undef>,
<undef>, 3 }` instead of `{ nil, nil, 3 }`, we would need an exception
to the normal value adjustment rule ...
- References:
- Empty? No. Array? No. Has? Yes., Dirk Laurie
- Re: Empty? No. Array? No. Has? Yes., steve donovan
- Re: Empty? No. Array? No. Has? Yes., Roberto Ierusalimschy
- Re: Empty? No. Array? No. Has? Yes., Sean Conner
- Re: Empty? No. Array? No. Has? Yes., Roberto Ierusalimschy
- Re: Empty? No. Array? No. Has? Yes., Andrew Starks
- Re: Empty? No. Array? No. Has? Yes., Philipp Janda
- Re: Empty? No. Array? No. Has? Yes., Andrew Starks
- Re: Empty? No. Array? No. Has? Yes., Philipp Janda
- Re: Empty? No. Array? No. Has? Yes., Andrew Starks