Re: q: nil in tables

[Stephan Hennig <sh-list@...>]

Am 17.03.2018 um 18:08 schrieb Coda Highland:
> On Sat, Mar 17, 2018 at 11:55 AM, Stephan Hennig <sh-list@posteo.net> wrote:
>> Am 17.03.2018 um 17:06 schrieb Stephan Hennig:
>>
>>> I tend to think tables with nil are constant size or grow only.  So
>>> here's a stupid question:
>>>
>> What use-case is there to have nil in tables /and/ to be able to
>> delete (any) values from the same tables?>
> One realistic example: Imagine a cache table that holds the results of
> expensive function calls. The function can return nil, so you have to
> be able to store that, and you need to be able to remove entries in it
> as they become stale.
> 
> Without the ability to delete keys distinctly from storing nil, you
> would have to use a singleton to act as a fake nil and then detect> that and replace it with a real nil at runtime. Possible, sure, but a
> bit ugly.

Or a second fall-back table containing a true value for all keys with a
nil value.

Anyway, when caching values you're pretty much into the metatable
business already.  That is, this use-case has already a requirement of
the same complexity as the Lua-ish way of storing nil in tables via
metatables already provides.  Nice example, but I don't see a pressing
need for a change in the language (undef) from this one.  (I do see a
need for easier handling of nil in tables, though.  But that need can be
satisfied with more metatable mechanisms as has been proposed by others
already.)


> Another realistic example: For performance reasons, you're trying to
> reuse tables as much as you can. If you need to be able to distinguish
> between a nil value and an absent key, then you HAVE to be able to
> properly delete keys if you're going to reuse tables.

A more tough one to discuss away. :-)

For the simple case of finally emptying a table containing nils in
preparation of reuse, a new function table.empty() can be provided that
does exactly that.

If single keys had to be removed during lifetime of a table, this
use-case has the following requirements

  a) performance (no metatables if possible),
  b) storing nil in tables,

This certainly required something like undef.  It is not quite a common
use-case, though, I guess.

Thanks for the examples, Coda!  May be obvious, but I'd just feel better
with tables with nils, but without undef.

Best regards,
Stephan Hennig