Re: Strong tables in Lua 5.4

[Hisham <h@...>]

On 20 March 2018 at 18:38, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Dibyendu Majumdar once stated:
>> On 19 March 2018 at 17:51, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> > 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.
>> >
>>
>> Hi, I agree partly with your idea. Maybe Lua can have a well defined
>> singleton object call MISSING or NONE or UNDEFINED. Say it is a global
>> value which is actually just a Userdata.
>
>   Um ... Roberto just said that "false" was introduced into Lua *just for
> this purpose*.

Which, with all due respect I obviously have towards Roberto, I think
it's a very odd choice and the wrong motivation for booleans. As a Lua
programmer, I love having first-class booleans in the language, but it
would never occur to me to use "false" them to represent "missing
value" -- false means false. And true is not useless in Lua, it means
true, and allows us to state our intent in an unambiguous and
interoperable way. Plus, if we didn't have booleans, we'd be
complaining not only about how to convert `null` to and from other
formats, but also `true` and `false`.

If I was to set out to fix the "holes in arrays/interop with JSON
etc." alone, then I think I would go with Dibyendu's idea and
introduce a new constant in the standard library, a lightuserdata
called NULL that contains a NULL C pointer. If the language predefined
NULL, I'm sure everyone would start using that as the convention for
converting to and from null (instead of our current situation where
each library declares its own json.null, ngx.null, etc.) This is a
sort of "solution by convention", akin to adding <stdbool.h> to C to
fix the lack of agreed-upon booleans.

However, the nils-in-tables proposal came up because the Lua Team is
clearly looking beyond this single practical problem that many of us
have and that was outlined in the previous paragraph. They are aiming
to solve that plus a number of quirks in the language (the things that
give birth to select(), table.pack() and table.unpack()) in one fell
swoop. I applaud them for going after the root cause.

But while many solutions can fix the former specific problem, with
various degrees of compatibility concerns — ranging from virtually
none (adding a NULL constant which can be easily emulated in 5.1-5.3)
to very high (anything that changes the default behavior of #t) —
addressing the issue of nils-in-tables in the proper general way (i.e.
make {...} really "store all arguments") cannot be done without a
considerable compatibility break.

-- Hisham