I agree *nearly* 100%, but syntactically 'nil' in Lua is treated much more like a special value. After all, I can compare a value to nil, return nil from a function, and pass nil to a function. When I code "return 1, nil, 2" in Lua most people would (perhaps loosely) say "the function returns three values, the 2nd of which is nil", and indeed PiL has stuff like that in several places. Indeed, one way to view a table is one having an infinite number of keys, most of which hold the value nil; this entire model is to my mind elegant, cunning, and minimalist (all good qualities).
Except for arrays, where nil has this odd side-effect of wiping out the "array-ness" of the sequence. After all, in my function return value example, putting nil in the 2nd return didn't somehow make the entire list of return values suddenly get truncated, nor does passing nil mid-way through a list of function arguments.
I'm actually ok with the oddity; every language has them, and the fact that Lua has so few is one of it's strengths. But that doesn't mean it *is* a bit odd, as is (even more so) the behavior of the # operator. When I train people in Lua, the array issue is always one of the ones that raises more eyebrows (with polite "really?" remarks) than any other.
--Tim
nil is a very strong language level concept. From the language level, at every position in a array you have something. If the index exists, there must be something there. And nil is not "something", it means "this does not exist"
