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

[Roberto Ierusalimschy <roberto@...>]

> 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?

The problems I am trying to solve are these:

1) A constructor like {x, y, z} should always create a sequence with
three elements. A constructor like {...} should always get all arguments
passed to a function. A constructor like {f(x)} should always get
all results returned by the function. '#' should always work on these
tables correctly.

2) A statement like 't[#t + 1] = x' should always add one more element
at the end of a sequence.

These are what confuse people all the time, these are what start new
rounds of discussions around '#'.

Once 'empty' and 'undef' are values, you break all those properties.

I think we cannot use a value to represent the absence of a value, no
matter how many no-value values we add. It is a contradiction. Several
languages followed this path, always with bad results.

-- Roberto