lua-users home
lua-l archive

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

> I think the problems stem from the fact that a vector and a hash under the hood are presented at language level as a single concept of a 'table'. It would be easier to implement and maintain, it seems, two separate language concepts of a vector and a hash, rather then doing all sorts of acrobatics in attempts to present them via a single language construct.

There is only one data container in Lua and it's the table, which is an
associative array: it stores pairs (key,value) where keys and values can
be anything (except that key cannot be nil). This is a very powerful
concept and one that is easy to understand and use. After all, there is
only one concept! This is what makes Lua Lua.

In other words, there is no concept of vector, lists, arrays, sets, hashes,
etc. in Lua. Only that single "set of pairs" concept, which is the table.

On the other hand, tables are powerful exactly because it's easy to
implement all kinds of data structures with tables. And now come the
problems. If you want to represent vector in Lua, you need to use integer
keys in tables. And now you want to know the "size" of the vector. The only
size that makes sense for tables is the number of pairs in it (pairs with
nil values do not count). However, this notion of size is not very useful
for tables in general and does not do the "right" thing for vectors that
have "holes" or tails of nils. The new # operator does the right thing for
tables that are used to represent vectors without holes. And it does not
promise to give you anything useful otherwise.

I don't think Lua needs two separate notions. The single notion is powerful.
Lua does try to cater for the common use of tables as arrays internally,
by providing a smart implementation that is efficient in time and space
when the table is used as an array. But this is an implementation feature;
we could go back to plain hash tables any time and the language would be
the same; except for some performance loss in some uses of tables as arrays.