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

[Dirk Laurie <dirk.laurie@...>]

2018-03-14 16:18 GMT+02:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
>> 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.
>
> I don't think these implementation details help this discussion, on the
> contrary.
>
> The implementation could be completely different, for instance an extra
> field in each table entry telling whether it is empty or not. Actually,
> this second implementation gives a much better mental model of the
> semantics then the real implementation, but it would be more expensive.

They are confusing, yes. Particularly because nil behaves like empty
and undef like nil. But bear with me while we make a thought
experiment.

Lua 5.3: There is a type 'nil' and a value also called 'nil'.

Experiment: There is a type 'nil' and two predefined values 'empty'
and 'undef'   both visible at the Lua level. If LUA_NILINTABLES is not
defined, they are the same and behave just like the value 'nil' does.
Otherwise there is a difference. 'undef' is actually quite close to
the present value 'nil': it is what too-short tuples are filled with;
it defines where a boundary in a table is. 'empty' behaves like the
empty value in the current implementation.

If we do 'nil=empty', the work1 implementation could also serve as an
implementation of this model.

The question is: is this model really conceptually worse? Would it not
in fact be quite useful to have access to both these values at the Lua
level?