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

[Duane Leslie <parakleta@...>]

Apologies to Roberto who got this 3 times (I fail at "Reply All")

On 15 Mar 2018, at 05:24, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

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

Personally I think this problem is better solved by creating a tuple type.  You essentially have this now with the userdata having multiple (but fixed) numbers of uservalues.  The tuple type is the most needed thing for me in Lua and you can bet I'll be all over this with the new userdata.

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

I disagree with this statement.  It is a programming error to assign nil to the end of a sequence and expect it to occupy a slot.  People should error check their values and something as simple as `t[#t+1] = x or false` will fix this.

Personally I think this new undef behaviour creates more problems than it solves.  I appreciate the attempt at backwards compatibility, but I don't think it is realistic to believe it can be achieved with a change as big as this, and I think it distracts from finding the best solution to the real issues.  Really, people shouldn't be using nil as a real value, and if they need an empty value it is simple enough to create a singleton to stand in for it if something is needed distinct from false.

In every case except the table constructor wrapping sequences the problem can already be solved in Lua with simple patterns or the help of metatables.  The table constructor for sequences naturally lends itself to tuples which would open up a whole new world of possibilities (sequence comparison, etc.), and is really now just a specially blessed version of the new userdata construct.  It would be nice to have a pretty syntax for it (maybe `[]` instead of `{}`), but even that's not necessary since you can just pass the sequence as arguments to a function call which creates the tuple.

Regards,

Duane.