Re: new "empty" value/type in Lua?

[Eike Decker <zet23t@...>]

Am 01.07.2013 20:44 schrieb "Roberto Ierusalimschy" <roberto@inf.puc-rio.br>:


>
> > Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
> > nil but introducing two new functions to the table library called
> > "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
> > deletion via assigning nil?
>
> At last something new and worth a discussion. Does anyone see problems/
> incompatibilities/etc. with this?

* Any former deletion of keys would not release memory thus creating
memory leaks. This could be subtle and unexpected and thus hard to
find.

* Next to that, unexpected behavior that used to work when dealing
with arrays could lead to new bug discoveries (but I would regard such
former code as bugged anyway) that would require attention.

* Also problematic could be regarded the behavior for weak tables. The
case for weak keys would be simple: If the key gets collected, the key
is deleted. For weak value tables, it's ambiguous - the key could be
deleted or the value could be set to nil. I don't know what would make
sense in that case. Maybe it only requires a decision and RTFM
messages when someone stumbles over it.

* Furthermore, iteration of deleted values would behave differently as
the values can actually be nil - so any pairs(t) call on tables can
all of a sudden return nils in case that the table is assigning nil
values for deletion.


Apart from that not much is crossing my mind that would be changed.
Deletion of keys was not often part of my code as in most cases I used
to throw away the entire table. I don't know how often values get
deleted from tables in other people code. But yes, any such behavior
needs to be revisited.

I still would think that an explicit deletion command would be more
clean because the nil assignment can be done unwantingly:

t[a],t[b] = t[b] -- deletion of t[b] afterwards - wanted or incomplete swap?

t[idx] = val -- if val is nil => deletion with all kind of wicked
consequences like "Why does iteration stop after 30 elements though
there should be 1000?" - this keeps happening all the time



>
> (But what is "[to]"?)

[to] would be used for ranged deleted but I now realize, that it would
not work as intended (regarding arrays and holes...), so I think it
should just be table.delete(t, key) as arguments.

>
> Keep in mind that #t would still be undefined for arrays with holes,
> but holes would be much less frequent...

True. But hole punching would not break the length operator any more,
which I would regard a great win.

Next to that, it might be useful in this context to consider reviving
an old table creation function that allowed specifying length of the
array part of a table... It would pre allocate an array with n nil
values and would provide means for more efficient table filling.

>
> -- Roberto


2013/7/1 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
>> Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
>> nil but introducing two new functions to the table library called
>> "table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
>> deletion via assigning nil?
>
> At last something new and worth a discussion. Does anyone see problems/
> incompatibilities/etc. with this?
>
> (But what is "[to]"?)
>
> Keep in mind that #t would still be undefined for arrays with holes,
> but holes would be much less frequent...
>
> -- Roberto