Re: Nnitpicks in the Lua 5.1 Reference Manual

[David Jones <drj@...>]

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