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

[Roberto Ierusalimschy <roberto@...>]

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

I don't think people understand the point about compatibility.

The new semantics is NOT COMPATIBLE with the old one. We know that. That
is why we are NOT TURNING THIS NEW SEMANTICS AS THE DEFAULT in Lua 5.4.
LUA 5.4 WILL BEHAVE EXACTLY AS LUA 5.3 REGARDING ASSIGNMENT OF NILS
TO TABLES.

To make it clear: We are NOT TURNING THIS NEW SEMANTICS AS THE DEFAULT
in Lua 5.4. (It is not the default even in this work version!!)
LUA 5.4 WILL BEHAVE EXACTLY AS LUA 5.3 REGARDING ASSIGNMENT OF NILS
TO TABLES.

What we are proposing is a path for compatibility. The goal of this new
syntax with undef is to allow us to write programs that are agnostic
about nils in tables. Old programs should not store nil in tables (as
it wouldn't work). If they write "a[i] = nil", there is a very high
probability that they want to delete the key from the table. If we
change that to "a[i] = undef", all work as before, but we made explicit
in the code (the "very high probability" becomes a certainty) that we
want to delete that key. In the far away future, when we release Lua 5.5
or Lua 5.6 or Lua 6.0, we may change the semantics to this new proposal.
Then, programs that followed these "good practices" would run unmodified
in this new semantics. With this flag in 5.4, we can even check whether
our programs are well adapted for this distant future.

Exactly because the semantics IS NOT CHANGING in Lua 5.4, we want a
syntax that is similar (and backward compatible) to Lua 5.3. If we can
erase a key with 'a[t]=nil' or with 'delete a[t]', but the former works
with previous Lua versions and the later does not, I would choose the
former.  If I can use 'a[t]=nil' or 'a[t]=undef', and both are backward
compatible with Lua 5.3, and I realise the later is clearer and "forward
compatible", then I could choose the later.

As I noticed that several people in the list did not understand this
point, I will repeat it: We are NOT TURNING THIS NEW SEMANTICS AS THE
DEFAULT in Lua 5.4. It is not the default even in this work version.
We (and everybody else) know it is imcompatible with the old semantics.
LUA 5.4 WILL BEHAVE EXACTLY AS LUA 5.3 REGARDING ASSIGNMENT OF NILS
TO TABLES.

-- Roberto