Re: Second class nil? Strong and weak nils in tables?

[Duck <duck@...>]

> Anyway, code like:
>
>   local t = {...}
>   for k = 1, #t do
>      local v = t[k]
>      do_something (k, v)
>   end
>
> seems clear enough...

That's exactly my point. That code is the clear and natural way to use 
{...}, but it also breaks whenever any of the args in ... is nil.

Converting a list into a table is lossy, precisely because you can't 
have explicit nils in tables.

Using tricks such as mapping nils into some other representation (e.g. 
null = {}) to allow them to go into the table and mapping them back to nil 
on the way out is an oft-suggested fudge..

..but it doesn't get away from the singularity (is that the right word?) 
caused by the "second class" nature of nil, which prevents lists being 
mapped into tables, and vice-versa.