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

[Oliver Kroth <oliver.kroth@...>]

> > Why is the new "undef" not used the other way round:
> >
> > A[2] = nil removes the entry from the table
> > A[2] = undef  puts a value in A[2] that reads 'nil'
> >
> > That would keep compatibility with Lua 5.3 and older
> We thought about something like that.
>
> The problem is neither 'a[t]=nil' nor 'a[t]=undef', but 'a[t]=x' when
> 'x' happens to be nil. This is what creates surreptitious holes in
> tables that leads to all the problems with '#t'. In the end, we would
> have something like this:
>
> x = nil; t[1] = x;    -- adds element
>           t[1] = nil;  -- remove element
>
> Rather strange...
>
> -- Roberto
Not sure if I did understand;
using Lua5.3 semantics:

x = nil; t[1] = x;  -- removes element

proposed new 'value' undef:
           t[1] = nil;   -- removes element, creates hole, reads nil
x = undef; t[1] = x;     -- removes element, creates hole, reads nil
           t[1] = undef; -- keeps element, no hole, reads nil

I have read that there are two subtypes being used; that may help here 
as well:

nil   = nil.remove
undef = nil.keep

           t[1] = nil;   -- removes element, creates hole, reads nil
x = undef; t[1] = x;     -- stores nil.keep in x, assignment to t[1] 
stores nil.keep, no hole, reads nil
           t[1] = undef; -- keeps element, no hole, reads nil (is nil.keep)

Would that work ?

--
Oliver