lua-users home
lua-l archive

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


On 17 April 2012 02:29, chris <csrl@gmx.com> wrote:
> Matthew Wild <mwild1 <at> gmail.com> writes:
>> On 16 April 2012 09:31,  <csrl <at> gmx.com> wrote:
>> > My point in this is that if #t returns a particular value n, it becomes
>> > surprising if each key of {1..n} does not index a non nil value in the
>> > table.
>>
>> It might be surprising, until you read the documentation.
>
> Reading the documentation obviously did not clarify it for me, hence my post. :(
>
>> > But in any case, I'd expect defined behavior rather than undefined
>> > behavior.  I can not wrap my head around how the above behavior might
>> > be defined.
>>
>> Re-read the first sentence of the documentation you linked, especially
>> the words "is only defined if". The documentation clearly says that
>> the length of non-sequence tables is *not* defined. That means you
>> cannot rely on it to give any particular value. It's not defined to be
>> random either though, so don't use it for a random number generator :)
>
> :)  Thanks for attempting to clarify it, as for me "clearly" was not so clear.
> To me the documentation stated that if the list was not a sequence that the
> length of the table is not defined, meaning that it is nil.  As that is not what
> my testing showed me, instead it showed rather aberrant behavior which caused
> confusion.  Slightly better wording would have been to say that in such a case
> the result of the length operator is 'undefined'.

Aha! Now I understand your issue. I can see how you might read the
text that way.

It's tricky to re-word the documentation, as I think "is undefined if"
could cause confusion just as easily as "is only defined if". I think
it would say "returns nil" if it really returned nil, but saying that
it can return any value isn't so easy.

Regards,
Matthew