Nnitpicks in the Lua 5.1 Reference Manual

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Nnitpicks in the Lua 5.1 Reference Manual

David Jones-2
Good work on the 5.1 release, I look forward to using it.

Naturally there are some very minor mistakes in the reference manual.

The description of tonumber(e, base) can be read to imply that
tonumber('c', 11) would be 12.  You need to say that "Characters
representing numbers that are not smaller than the specified base are
invalid".  Let's not forget that until ANSI said otherwise many C
compilers treated 089 as a valid "octal" constant.

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".  Overall I think
it's slightly more consistent to say that tables can have fields with
value nil but that the iterators ignore fields with a nil value.  Then
you might need to change the last paragraph of the description of
"next" to say "The behavior of next is undefined if, during the
traversal, you assign any value to a field that previously had a nil
value".

2.5.5 The Length Operator should say "The length of a table t is
defined to be any non-negative integer index n such that ..."

Section 2.5.9 has the sentence: "If a vararg expression is used inside
another expression or in the middle of a list of expressions, then its
return list is adjusted to one element."  The phrase "its return list"
is confusing.  The return list of what?  What's a return list anyway?  
I think it would be better to just say "it" or "the vararg expression"
instead of "its return list".

David Jones

Reply | Threaded
Open this post in threaded view
|

Re: Nnitpicks in the Lua 5.1 Reference Manual

Aaron Brown
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

Sorry again for this not being threaded.  I'm working on
getting Hotmail to not throw away messages from this list.

--
Aaron
Reply | Threaded
Open this post in threaded view
|

Re: Nnitpicks in the Lua 5.1 Reference Manual

David Jones-2

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