Re: Virgin tables

[Axel Kittenberger <axkibe@...>]

> There have been complaints in these threads about the result of the
> length operator not being deterministic -- that the same Lua code can
> return different answers on different implementations -- but this is a
> red herring.  The length operator could easily be made deterministic
> by specifying precisely how the unbounded binary search must be
> performed.  Then the answer would no longer be nondeterministic, but
> it would still be *arbitrary*.  It still wouldn't be very useful for
> non-array tables, and all of the complaints in these threads would
> continue.

Defining the binary search is not what I ment. I ment I dont care if #
for a non-list is number of elements, last key of ipairs(), largest
key, nil or even error. But any would IMHO make Lua a better language
with one pitfall less for the not-so-much-expert coder. And from the
notion of e.g. using "or" and "and" instead of || and &&, or defining
the sequence of calculation of op1() + op2() it was my imperssion it
tries to do that.

Its all cool that table.insert() uses #, but this is as far I can see
the one and only use of # on non-lists. So table.insert() could become
a C-implementation and # for non-lists any else meaning. Heck I might
not even miss the # operator that much. As has been argued against any
# proposals that its easier to code in Lua whatever you want it to
mean, you might also keep the length of lists yourself if you need it.