lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



On Thursday, July 4, 2013, Philipp Janda wrote:
Snip..
type({empty(), empty(),3})[2])
--> nil, undefined

That is basically the explicit/implicit (defined/undefined) nil approach, not the table-index-is-vararg approach.
The former requires less changes to Lua as is, but introduces a new value which inherits the problems of the current nil value, and it makes __index messy.
The later is basically an alternative to raising an error when accessing an undefined value in a table, and it doesn't need a new value.
Both approaches need an incompatible way of deleting values. In fact *any* approach which allows storing nils needs a new syntax for removing values (or new syntax for storing nil, `t[n] = nil` cannot be used for both)

It must be said that, as I understand it, Lua *does* store nils in tables, you just can't see that it is doing it. If I'm wrong on that point, I'd like to be corrected. 

Either way, because one could find out if the reported nil was set or merely non-existent does not necessarily require or imply a change in ipairs. By default, it still stops at a reported nil value.  Therefore, it wouldn't necessarily require a method to actually remove an index, nil or otherwise. Although that would be very helpful, popping via t[#t] would still work. It's only the *ability* to discover the source of why nil was returned.  
 


Another syntactic trick may be too have lua do this:

local foo

select("#", foo) --> 1
select("#", (foo)) --> 1
select("#", baz) --> 1 -- today's behavior, intact thus far

select("#", (baz)) --> 0 -- new behavior.

This is a bad idea in both approaches:
It reuses existing syntax for a completely different (and incompatible) effect -- it actually *reverses* the usual behaviour in the table-index-is-vararg method.

how so?
 
And it doesn't really apply to the explicit/implicit nil method, because there are no variable value lists involved (baz always has exactly one value) ..

The parens were in the spirit of anonymous functions and tables:
(function() print("hi.") end)()
--> hi. 
print(({"hi."})[1])
--> hi.

However, your point is fair enough. It was an attempt to change as little as possible.

The justification for this approach uses the following logic: 

1: In `select`, a function call to a function with no return value reports the desired answer for this discussion, but a non-existing variable name does not. This makes perfect sense, as Lua is defined, today. However, one can see why it is a bit of a head scratcher, at first.  So, this makes change somewhat easier to accept. Without some kind of syntax change, however, you're likely to break more code than otherwise. 

2: As illustrated, surrounding an anonymous table or function in parens allows you to index or call it. 

3: That seemed somewhat related to the idea that surrounding any value in perens could also be reasonably taken to mean "don't promote this." 

As an distracting example,  perhaps it could also mean:

print("10")  + 10 )
--error 
...but (2 + "10") + 10 would still be 22. (Appropriate, given the nature of variable promotion :)

Anyway, the syntax was only a throwaway idea and your point is valid. Please disregard. :)
 

Philipp