But nil isn't really first-class, because it cannot really be stored
as value into tables.
You can definitely store nil in a table in the sense that t[1]=nil
gives
you back nil when you read t[1].
"storing" it in a table makes the key go away
This reflects our view of tables, which are containers for values.
Keys play a secondary role. When there is no value, there's no key.
This behavior is *not* due to some flaw in nil.
not show up on i/pairs
One way to think about a table is that it initially contains *all*
pairs
(key,nil), for all possible keys. You wouldn't want pairs to show
them all :-)