 |
lua-l archive |
|
|
||
|
On Mar 30, 2006, at 14:40, Aaron Brown wrote:
In <http://lua-users.org/lists/lua-l/2006-03/msg00770.html> David Jones wrote:Section 2.2 says tables "can contain values of all types (except nil)", but this is inconsistent with ipairs which says "up to the first integer key with a nil value in the table" (keys can't have nil values), and "next" which says "There is no difference between a field not present in a table or a field with value nil".Roberto's reply to a similar comment was:Tables cannot contain nils, but arrays can.http://lua-users.org/lists/lua-l/2006-03/msg00576.html
This has got to stop.Claiming that tables cannot contain nil, but arrays can contain nil is doublethink. In Lua it's blatantly obvious that arrays are tables. It's not the case that arrays are merely represented by tables; in Lua you can't keep that secret. Arrays _are_ second class citizens. Every array is a table, I can tell because "type" tells me so. Every function and operator to which I can pass a table I can also pass an array. Trying to maintain the fiction that an array is a separate datatype from tables is a waste of effort.
ipairs operates on _tables_ so statements like "the first integer key with a nil value in the table" are meaningless.
I think it's much simpler if you accept that tables _can_ contain nil values, because then statements like "the first integer key with a nil value", which we all understand intuitively, have a proper meaning. The current definition of the length operator uses Lua expression syntax, "t[n+1] is nil", which avoids this issue. I don't know whether that's cunning or not.
An array is just an interpretation of a table, it's not a separate datatype.
David Jones