Re: [ANN] Lua 5.4.0 (work1) now available

[Andrew Starks <andrew@...>]

On Wed, Mar 14, 2018 at 08:14 Dirk Laurie <dirk.laurie@gmail.com> wrote:

2018-03-14 14:46 GMT+02:00 pocomane <pocomane_7a@pocomane.com>:
> Some opinions about undef. Right now, nil is needed for:
> 1) skip some arguments or return values in a function call
> 2) check presence in tables or remove something from them
> 3) Other ?
>
> IMHO, the mixed solution (nil/value for 1 while undef/keyword for 2) is very
> little lua-ish. It is complex and difficult to explain, also if it just adds an
> handfuill of exception to care of. This because both 1 and 2 in our human mind
> are recognized to model the same thing: something "Missing".
>
> I am not saying that undef should be removed as a test feature. On the
> contrary, it would be nice to have the possibility to play with a full solution
> that works also for 1. I also theoretically prefer "Keyword/no-value" semantic.
> But I really do not see any simple way to keep this semantic in 1.
>
> I mean: if I can pass something to a function, and I can get it back from a
> call... well it is a value!

If you enable LUA_NILINTABLES (as explain in detail in a new thread),
there is another value of type nil, call it 'empty'. You can't tell
the difference between the values 'nil' and 'empty' at the level of
the API, let alone in Lua.

But for the sake of the argument, suppose you could. When you say
"t[4]=nil", what really happens is the equivalent of
"rawset(t,4,empty)", and when you say "t[4]=undef", what really
happens is the equivalent of "rawset(t,4,nil)".

At the level where '#' is calculated, 'empty' is distinct from 'nil'
and so the table does not have a hole there.

[1] Nils in tables in Lua 5.4.0 (worki1) (Was: [ANN] ...now available

Doesn’t it make tables behave closer to multiple return values? Now, if you store return values in a table, you have a way to know the number of values returned, even if there are trailing nils. You can also reliably get this answer if the nils aren’t trailing. 

‘t.n’ was the other way to do this, but from a symmetry standpoint, it appears to be a little cleaner. 

If you had some datamodel where you were storing large objects as keys, you would need to update your code.