lua-users home
lua-l archive

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


Philippe Fremy wrote:
As far as I know, it is not possible to know from a function return value how many values where just returned. You can pack them and unpack them but it is not possible to know in advance how many of them are there. In my opinion, the return value of a function in lua is a kind of hidden list.

Ok, I admit returning a variable number of objects in a function is a bad practice, but what I see is that there seem to be a few places in lua where list would make sense but are not used because they are not available. I am not familiar enough with lua yet to point all of them out though. But the pack/unpack thing keep bothering me. It is really build a list object but don't tell them.

So just point out only some of them, it would enlighten us.
I am still lost how lists are so crucial, but then again, beside their use in C/C++, I am not very familiar with them.

Something, where having a dedicated list object would really boost the performance
of the application?

I believe that you can apply some optimisation for lists, that you can not get from tables, because a list is a more simple type. While tables do have a good emulation for lists, they remain tables and can only be optimised as tables. In cases where you only need a list and not a table, you would probably get a performance boost.

Seems a bit fuzzy as explaination...

For example, if you have a list of 10000 items, a lua table is going to store the keys 1 to 10000 and to store the values too. A list would only store the values. Iterating upon such a list is also quicker than over the equivalent table because a double-linked list is easier to iterate over than a list of hash.

Here, I disagree. A table: store keys and values. A list: store values and two pointers per value if it is a double-linked list. Where the list is less memory hungry?

A Lua array, ie. a table indexed by integers, AFAIK, isn't managed by hashing but by index. So we don't have only one type but two, even if they have similar syntax. Lists are more likely to be managed by arrays (so only values are stored, not even a key) and iterating over them is fast. Granted, insertion/removing is probably slower here.

Another thing about lists is that it is a very common and easy to understand type. People having little experience in programming can understand what a list is very quickly. A map/hash/table is more difficult to grab.

Really? Again, we have arrays, which is a very basic type. And I am not sure about the simplicity of either type. We should ask real beginners...

Another thing that I dislike about table as lists is that when you do:
t = {1,2,3,4,5,6}, lua does a lot of things under the table to make it look like a list. This is not good because it adds complexity to a simple expression that nobody expect to lead to complex situations.

Are you sure of what you are saying? I believe Lua have been carefully designed and optimized, hence the distinction between tables and arrays.

I have no strong opinion on the need of a separate type, but I am not overly convinced by your arguments, which seems to result more from gut feelings than from performance tests or source study.

Lot of people coming from other languages want features from their favorite language (// comments, bitwise operators (I would like that ;-P), += operators, lists, tuples, etc.). They don't accept Lua as it is, with its originality and specific syntax/style. Note that sometime it helps Lua to evolve, but most suggestions are just discarded because they are not relevant.

--
Philippe Lhoste
--  (near) Paris -- France
--  Professional programmer and amateur artist
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --