Re: Lua design : why no lists ?

[Philippe Lhoste <PhiLho@...>]

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