Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix various issues and cleanup whitespace #9

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

catwell
Copy link
Contributor

@catwell catwell commented Nov 20, 2013

No description provided.

- better explanation of the length operator
- no functions in table constructors
- spaces after { and before }
list[2] = nil
list[3] = "item"

print(#list) -- undefined result
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should say that it returns 1 rather than the expected 3.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With a given Lua implementation. But the definition in the language is even worse. In Lua 5.1:

any integer index n such that t[n] is not nil and t[n+1] is nil

So it could be 1 or 3.

In Lua 5.2 it is even clearer:

Unless a __len metamethod is given, the length of a table t is only defined if the table is a sequence, that is, the set of its positive numeric keys is equal to {1..n} for some integer n

So the operator could return anything. Or crash your program, for that matter. Actually I expect some later Lua implementations to raise an error in that situation.

Anyway, my point is: you cannot rely on it being 3 but you cannot rely on it being 1 either.

EDIT: If you think this undefined stuff is theoretical, guess what this prints:

print(#{1, 2, nil, 3})

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true; maybe expand it as result depends on Lua implementation, then?

I admit, I only tested it in Lua 5.1.5 and Luajit 2.0.2 to confirm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it depends on the implementation. And it is not consistent even on Lua 5.1.5. As I said in my edit above, if you put the hole just one step further it doesn't give the same answer:

Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> list = {}
> list[1] = "item"
> list[2] = "item"
> list[3] = nil
> list[4] = "item"
> =#list
4

If you are interested in the "why" see the implementation. Hint: binary search.

@ajacksified
Copy link
Member

Thanks for the cleanup! Just the one note above.

@ghost
Copy link

ghost commented Nov 25, 2013

It was very nice of catwell to provide a pull request with the applied fixes and I can not understand the hold up here. The return value of the length operator on a table which is not a sequence, and in the case of 5.2 does not have a __len metamethod, is not defined.

@ajacksified
Copy link
Member

@aDevilInMe No hold up, I just have been very busy and haven't had a chance to merge. Will do so, after I fix the merge conflict, once I have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants