Re: Definition of table.insert

[Henning Diedrich <hd2010@...>]

Hi David,

On 1/8/11 12:55 PM, David Kastrup wrote:

t = { 1, 2, 3, 4, 5 }
print("Before:", unpack(t, 1, 5))
for i = #t, 3, -1 do
  t[i + 1] = t[i]
end
t[3] = nil
print("After:", unpack(t, 1, 6))

(Strictly speaking that is not a nil, but a "hole", but that is matter
of terminology.)

No, it isn't.  If I now do t[4]=nil; t[5]=nil; t[6]=nil I have _not_
touched t[3] at all, but clearly the table ends up with length 2.  So
there definitely has not been a value at index 3.

I wonder if you can use length, as defined by #t, in that argument about nils and holes in this way. It may be circular reasoning, as one definition supports the other but both are in the end arbitrary - informed by down to earth considerations probably quite removed from the lofty question of nil's citizenship.

Not trying to be picky! Right on the surface, #t is very sensitive to holes, even if it does not count them per se.

It is terminology in the end. Under the surface, there /are/ holes, and nils in tables, as two distinct states. We are only having this discussion because some feel it could be 'hidden' in a better way then is currently the case. Others feel that it could be more beneficent to be open about it, or that they would like to have 'nils' as first class values.

But as it is now, I guess it simply shows, though it should not. I'd say, like, there is hidden state leaking out from underneath causing side effects. Pretending it's just a matter of the right attitude and acceptance won't make the issues go away. It would all draw no attention if it was not sticking out. And belittling those who see an issue, as always, makes little sense.

Below, just to back it up, NOT to say that it SHOULD matter. But where I say that maybe it 'shines through' too much, these are the actual table-nils at the core that do in fact 'exist': a sample where nil values in the table are looked up, for re-use. Actual entries that can carry anything, and also nils. Those actual, plain entries of nil in the table implementation that we should not have to worry about at all and that should be entirely transparent seen from above:

static Node *getfreepos (Table *t) {
    while (t->lastfree-- > t->node) {
        if (ttisnil(gkey(t->lastfree)))
            return t->lastfree;
    }
    return NULL;  /* could not find a free place */
}

Again, the above is not a reason for anything. It is exactly what should be hidden better in my view.

Note that I did *not* know about these nils and 'true holes' underneath, but first started wondering about #t and insert(). I started looking into it because as it is, it's not clean to my mind and while it is clearly presumptuous, I think there could be a better way, even though Roberto and Luiz clearly state that currently, there is not.

I have a clear 'cause': I want Lua to be safe. I do think some arguments do not do justice to the explicit and real target audience of Lua.

Henning


--
Henning Diedrich
CEO

Eonblast Corporation
h...@eonblast.com
+1.404.418.5002 w
www.eonblast.com

This email contains confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is prohibited.