Re: ltable.c: observations and questions

[RLake@...]

See the thread around here: 
http://lua-users.org/lists/lua-l/2003-05/msg00188.html

> t = {a=1,b=2,c=3}

> Since the keys are strings, they will of course occupy the hash part of
> the table. Now set

> t.a = nil; t.b = nil; t.c = nil

> This removes the entries, but doesn't shrink the table (which will have
> size 4, i.e. 2^2). At least, this assumes that the table was originally
> created with both hash part and array part of size 0, but since
> OP_NEWTABLE is only ever emitted with these values set to 0, I think
> that's a safe assumption.

I don't think that is quite right (the OP_NEWTABLE comment) but in any
case, I think this behaviour is not awful. It is quite possible (if
the table is not weak-keyed) that the key will be used again, in
which case leaving it in the table does little or no harm, and
avoids recreating it later. In any case, if the hash table gets
to be full, the table will be rehashed and then shrink if it
is mostly empty.

You are quite correct about numeric keys, and it may be
an issue in some applications. However, not freeing
memory instantly is not necessarily a problem, and the
memory will get recycled when the table grows. In fact,
in your example, I think it will happen right away because
the key 1 would fill the table up, and hash tables are 
required to always have one free slot.