lua-users home
lua-l archive

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

Well... I would generally say that I am not totally happy with the way
arrays and lists in Lua work. It's probably the only thing I would
change right now if I was to change something in the language.

Putting lists and maps in one structure is a little weird. It tends to
favor the maps I'd say. Arrays, technically, are usually things that
take a linear space in memory. Processors understand arrays easily.
However, the Lua structure for arrays is more like a map with
integers. It's a really different thing, and sometimes it shows in its

I find the relation between nil and lists also confusing.

Java lists are very clear. They have a length, you can put anything in
any position, including nil, and there are no "gaps" anywhere. (Except
if you consider "nil" a gap...)

Either way, it is very simple and straightforward. Lua arrays kinda
keep confusing me. Their size can be different from their length which
I find quite strange to say the least.

Also, I saw a confusing implementation of the length operator in kahlua:

	public final int len() {
		int high = keys.length;
		int low = 0;
		while (low < high) {
			int middle = (high + low + 1) >> 1;
			Double key = LuaState.toDouble(middle);
			Object value = rawget(key);
			if (value == null) {
				high = middle - 1;
			} else {
				low = middle;
		return low;

It's obviously a binary search to find the highest key. But does it
even work? If there are nils in the table, it begins to act randomly.
It may, among others, return the key before the lowest nil - or the
highest key in the array.

I have to say: Arrays in Lua are indeed a little confusing.


On Sat, Oct 1, 2011 at 7:55 PM, Michal Kottman <> wrote:
> On 1 October 2011 19:43, Stefan Reich
> <> wrote:
>> Why is that done? Strikes me as rather confusing. (The OP obviously
>> fell for it too.)
> The other way round is also confusing sometimes - some functions
> return 'nil, error' in case they fail. This is a common idiom in
> places where you do not want to throw an error (like