Re: table insertion [was: Lua 5.1 (work2) now available]

[David Given <dg@...>]

Romulo Bahiense wrote:
> I feel very confortable with the syntax << t[] = 'newvalue' >>. PHP does 
> it and it is extremely easy - at least for me.

As a long-time C and C++ programmer, I'd like to cast my totally irrelevant 
vote for #. * means something quite different to me.

For dealing with segments of arrays, has anyone considered using some kind of 
slice notation?

Given that the tables we're dealing with here are always going to be arrays 
(they are, right?), this means that it's guaranteed that the only indices 
we're going to be interested in will start at 1 and go up. There may be other 
items, but we don't care.

So, let t[start, len] represent a slice of the array.

t[index, 1] = 42
...is equivalent to t[index] = 42.

t[index, 1] = {1, 2, 3, 4}
...deletes the item at index and inserts four entries in its place.

t[index, 0] = {1, 2, 3, 4}
...inserts four entries just before index.

t[index, 1] = {}
...deletes index.

t[1, #t] = {1, 2, 3, 4}
...deletes all items in the table and replaces them --- note that the table 
hasn't changed, only it's contents.

Naturally, all these can be used as r-values, too. t[index, 0] won't be useful 
as it'll always return {}. Negative indices count from the end of the array. 
It might be useful for 0 to refer to the hypothetical item immediately after 
the array, or this might just be confusing.

This means that a stack becomes:

function stackPush(t, v) t[0, 0] = v; end
function stackPop(t) local v = t[-1, 1]; t[-1, 1] = {}; return v; end

A queue becomes:

function queuePush(t, v) t[0, 0] = v; end
function stackPop(t) local v = t[1, 1]; t[1, 1] = {}; return v; end

It's a little ugly having to use [index, 1] if you want the negative-index 
behaviour. You can't use [index] because that conflicts with a field lookup. 
It might be interesting to have a flag you can set on a table to indicate that 
all integer indices have this extended behaviour.

(A variant system would use t[start, end]. This means that t[index] is 
equivalent to t[index, index]. This way you can refer to the whole contents 
with t[1, -1], but it's more fiddly to insert items.)

*shrug* Python has something like this, and it works very well there. I know 
Lua isn't the same kind of language, but remember, wholesale theft is the 
sincerest form of flattery...

[...]
> And an iteration in that table won't always give you in the order they 
> were pushed: key1 = "val1", key2 = "val2", key3 = "val3", ...

Well, no, it can't and still be fast. Preserving the order means that either 
(a) it has to store the items in a linear list, which means that it's very 
slow doing random access because it has to search through the list until it 
finds the entry you wanted, or (b) it has to store the order in a seperate 
table, which leads to nasty issues with keeping them in sync.

Currently entries are stored in a tree, I forget which kind, indexed by the 
key's hash value. This gives very fast lookup. I don't know of *any* kind of 
tree where the order the items are added are preserved.

[...]
> ps: I know I could make an integer-indexed table and use others tables 
> as values to store any data I need to be available in the 'creation order'.

Yup, that's the way to do it. Easy enough to wrap up in a class, if you want it.

--
[insert interesting .sig here]