Re: Definition of table.insert

[Alexander Gladysh <agladysh@...>]

On Sat, Jan 8, 2011 at 17:09, David Kastrup <dak@gnu.org> wrote:
> Alexander Gladysh <agladysh@gmail.com> writes:
>> On Sat, Jan 8, 2011 at 14:55, David Kastrup <dak@gnu.org> wrote:
>>> Alexander Gladysh <agladysh@gmail.com> writes:
>>>> On Sat, Jan 8, 2011 at 14:40, David Kastrup <dak@gnu.org> wrote:
>>>>> Alexander Gladysh <agladysh@gmail.com> writes:
>>>>>> On Sat, Jan 8, 2011 at 13:28, David Kastrup <dak@gnu.org> wrote:

>>>>> There is no way to insert nil in a table.  No matter what the user
>>>>> wants.

>>>> Hmm. Why not?

>>>> 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 am sorry, but I did not speak about "value". I did speak about nil
>> or a hole.

> If you differentiate between the two, you clearly consider nil a value.

Please re-read what I said above (in braces). I apologize for my
imperfect English if that is the reason of our misunderstanding.

I do not differentiate between the nil and the hole in the table —
that would make no sense.

>> I also haven't mentioned length of the table.

> Just because you did not think through the consequences of your
> statement, it does not mean nobody else can.

I'm sorry, I do not quite understand that statement. What do you want to say?

I merely wanted to say that may be legitimate cases when the length of
the table (that is, result of #t) does not matter.

We're discussing whether we should treat table.insert(t, n, nil) as a
noop, or not.

I'm saying that there are legitimate cases when user may want to
insert a nil in the table.

Alexander.