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

["Soni \"They/Them\" L." <fakedme@...>]

On 2018-03-15 08:40 AM, Viacheslav Usov wrote:
> On Wed, Mar 14, 2018 at 7:59 PM, Roberto Ierusalimschy 
> <roberto@inf.puc-rio.br <mailto:roberto@inf.puc-rio.br>> wrote:
>
> > The proposed syntax would allow programs written for 5.4 to run on 
> 5.3 without changes (pending metamethods), and would also allow 
> programs written for Lua 5.3 to be written with undef (only as an 
> idiom), so that they would more easily migrate to a future version of 
> Lua where nil-in-table would be the default semantics (if ever there 
> will be such version).
>
> Obviously, the introduction of 'undef' as a new keyword is only fully 
> compatible with existing (bug-free) Lua code when it does not use 
> undef at all, or when it is used as a read-only global variable that 
> is never assigned (which is a very brittle assumption). Any other use 
> of undef will be incompatible. There are largely three cases:
>
> 1. Compile-time incompatibilities, such as local undef = foo, function 
> undef() end, undef = bar, table.undef = baz, etc. Any existing code 
> that does that will have to be fixed.
> 2. Silently broken code. Any existing code that does the equivalent of 
> _ENV['undef'] = foo with a subsequent use of an equivalent of 
> table.foo = undef, will silently do something unexpected by its authors.
> 3. Piece-wise silently broken code, which is the result of case (1) 
> fixed in some way where undef was previously defined as a non-nil 
> entity, and the code left with the equivalent of table.foo = undef, 
> which was originally written under the assumption that undef is 
> something non-nil. Given the nature of the typical use of Lua, where 
> scripts normally are not loaded ahead of time and old code may be 
> floating around for a very long time, this can be quite nasty.
>
> I am not convinced that the noble goal of "compatibility" of'undef 
> between 5.3 and 5.4 outweighs these compatibility problems.
>
> Secondly, there is another problem, which is probably much bigger than 
> the above. There is a lot of Lua code that thinks table.foo = nil 
> removes foo from the table. That code, when run in a system where that 
> leaves foo in the table, albeit with a nil value, can run into serious 
> performance problems, silently again. Can we seriously believe that it 
> is going to be a simple matter to migrate all the "significant" code 
> to the new paradigm? I am afraid that will make the uptake of 5.4 
> difficult.

Tables don't shrink. They only grow.

> Cheers,
> V.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.