lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hisham suggestion seems quite fair. Why not leave the nil in tables for lua 6 and plan it some more as that change will only deepens the lua5.1> libraries compatibility problem? Maybe, a new constant value is the way to go, maybe the current undef approach is the best, maybe a new function to table, maybe something entirely out-of-the-box, who knows ...

To be fair, the need for nil's in tables is real, but workarounds for it are not that scary. Without it, people could focus on the other introduced features of 5.4 and speed up adoption. A faster interpreter without compatibility concerns is usually the kind of version bump that wakes up people to update their code.


2018-03-19 14:51 GMT-03:00 Dirk Laurie <dirk.laurie@gmail.com>:
2018-03-19 18:16 GMT+02:00 Hisham <h@hisham.hm>:
> On 17 March 2018 at 03:32, Philipp Janda <siffiejoe@gmx.net> wrote:
>> I think that storing nils in tables is worth a break in backwards
>> compatibility. We should just call it Lua 6.0 and design a nicer syntax for
>> deleting keys.
>
> I fully agree with this.
>
> Lua 6.0 with nils-in-tables will be an excellent language for new
> green-field projects (scripting for the next big game, etc.) but there
> is no viable "path for compatibility" that makes a language with
> nils-in-tables fit in the Lua 5.x ecosystem.
>
> I think this is the main disconnect (among many) in this whole
> conversation: considering ecosystems.
...
> Every attempt of smoothing out the incompatibility ("strong tables",
> undef syntax hack, etc.), while well-intentioned, just adds terrible,
> terrible pitfalls to the language (e.g. "Of course you may not pass a
> strong table to old libraries").
>
> Adding nils-in-tables is a bold move and everyone seems to agree it
> moves the language forward. But it is a major breaking change, on par
> with the removal of old-style %v upvalues and introducing proper
> lexical scoping. If this is added:
>
> * it won't make sense to call this anything other than Lua 6.0
> * any attempts at making a compatibility bridge will mean that the
> entire existing Lua 5.x ecosystem is "silently broken by default" on
> Lua 6.0

If it is that revolutionary and new, then why reuse an existing term
that has been one of the mainstays of Lua?

A breaking change is unnecessary.

The value 'nil' should be what it always has been, and act like it
always has done. Instead of 'nil' changing its spots, with the devious
'undef' brought in to simulate the job 'nil' has always done, this new
animal that can be stored in tables should have a different name.

I.e. the "implementation detail" should not be an implementation
detail, it should be visible.

Lua 5.4 should have a constant of type nil called 'null' [1]. Not a
new keyword, only a new predefined value.

All the functionality aimed for with nil-in-tables can be achieved this way.

- Being of type nil, 'null' by itself tests false.
- Not being equal to nil, 'nil' is a non-hole.
- Can be preassigned to global values (or a value in any table) so
that __index can just signal an error.

[1] Or "empty" or whatever, but the name "null" fits in with JSON.




--
"A arrogância é a arma dos fracos."

===========================
Me. Italo Moreira Campelo Maia
Co-fundador do Grupo de Usuários Python do Ceará
Secretário ForHacker (fb.com/ForHackerSpace)
Desenvolvedor Full-Stack, Escritor, Empresário, Visionário
-----------------------------------------------------
Meu Livro, Site, Blog
===========================