 |
lua-l archive |
|
|
||
|
> 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