Strong tables in Lua 5.4

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Strong tables in Lua 5.4

Dirk Laurie-2
Define a "strong table" as one in which 't[k]=nil' does not remove the
key, it stores nil.

In Lua 5.4 (work1), all or no tables are strong, depending on
LUA_NILINTABLE. A new keyword 'undef' is needed to remove a key from a
strong table.

If instead of that, a hitherto unused letter of the __mode metafield
(say 'n') is used to indicate whether a table is strong, then
(a) strong and non-strong tables could coexist in the same code;
(b) no compiler variable would be needed

To remove a key from a strong table, a function table.undef could be
supplied that temporarily replaces 'n' in __mode by a neutral letter
and does a rawset.

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Dirk Laurie-2
2018-03-16 13:31 GMT+02:00 Dirk Laurie <[hidden email]>:

> Define a "strong table" as one in which 't[k]=nil' does not remove the
> key, it stores nil.
>
> In Lua 5.4 (work1), all or no tables are strong, depending on
> LUA_NILINTABLE. A new keyword 'undef' is needed to remove a key from a
> strong table.
>
> If instead of that, a hitherto unused letter of the __mode metafield
> (say 'n') is used to indicate whether a table is strong, then
> (a) strong and non-strong tables could coexist in the same code;
> (b) no compiler variable would be needed
>
> To remove a key from a strong table, a function table.undef could be
> supplied that temporarily replaces 'n' in __mode by a neutral letter
> and does a rawset.

On second thought, that function must not be supplied. Really removing
a key from a strong table should be not be made easy. The user can
write that function if foolhardy enough.

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

pocomane
In reply to this post by Dirk Laurie-2
On Fri, Mar 16, 2018 at 12:31 PM, Dirk Laurie <[hidden email]> wrote:

> Define a "strong table" as one in which 't[k]=nil' does not remove the
> key, it stores nil.
>
> In Lua 5.4 (work1), all or no tables are strong, depending on
> LUA_NILINTABLE. A new keyword 'undef' is needed to remove a key from a
> strong table.
>
> If instead of that, a hitherto unused letter of the __mode metafield
> (say 'n') is used to indicate whether a table is strong, then
> (a) strong and non-strong tables could coexist in the same code;
> (b) no compiler variable would be needed
>

I really like it.
Just a variation to address the issues that Roberto stated in the udef thread:
- Only the empty table constructor `{}` make a "Normal" table
- All the other table constructors, e.g. '{..}' or '{a_func()}', etc,
generate strong tables by defaults.

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

pocomane
On Fri, Mar 16, 2018 at 1:03 PM, pocomane <[hidden email]> wrote:
> Just a variation to address the issues that Roberto stated in the udef thread:
> - Only the empty table constructor `{}` make a "Normal" table
> - All the other table constructors, e.g. '{..}' or '{a_func()}', etc,
> generate strong tables by defaults.

Or better:
- When created with contructors like `{...}` or `{a_func()}` the table
will store nil as if it was a strong table, but then it will be
switched to the "Normal" mode.

I think that, probably, the Dirk's proposal can fully replace 'undef'.
Maybe we do not need a way to check field presence neither (aka `t.x
== undef`).

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Sean Conner
In reply to this post by pocomane
It was thus said that the Great pocomane once stated:
>
> - All the other table constructors, e.g. '{..}' or '{a_func()}', etc,
> generate strong tables by defaults.

  No!  That will break too much existing Lua code.  Well, not "break"
exactly, but cause programs to consume memory as the GC won't be able to
shrink tables.

  -spc


 

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Sean Conner
In reply to this post by Dirk Laurie-2

  The problem of "storing" nils in tables deals exclusively with sequences.
The whole notion of a sequence is a bit odd (given how it calculates the
length), especially given that Lua *does* use an array (as an optimization)
to back them up (in most cases):

typedef struct Table {
  CommonHeader;
  lu_byte flags;  /* 1<<p means tagmethod(p) is not present */
  lu_byte lsizenode;  /* log2 of size of 'node' array */
  unsigned int sizearray;  /* size of 'array' array */ // !!!!!
  TValue *array;  /* array part */ // !!!!!
  Node *node;
  Node *lastfree;  /* any free position is before this position */
  struct Table *metatable;
  GCObject *gclist;
} Table;

  One proposal could be to modify the structure slightly (only show relevant
fields):

        typedef struct Table {
          unsigned int sizearray;  /* size of 'array' array */
          unsigned int lenarray;  /* current length of array */
          TValue *array;  /* array part */
        } Table;

  The intent is such that #array will simply push the value of lenarray
instead of the O(ln) search it does now.  lenarray (and sizearray if we need
to shrink or grow the array) only change when you do:

        t[#t + 1] = somevalue;
        table.insert(t,somevalue);

        table.remove(t)
        table.remove(t,<some length <= #t>)

  Creating a sequence is pretty much the same:

        t = { 1 , 2 , nil , 4 , 5 } -- #t == 5

  Although, while *this* may generate a "proper sequence":

        t = { [1] = 1 , [2] = 2 , [3] = 3 , [4] = 4 , [5] = 5 }

this *might not*:

        t = { [3] = 3 , [5] = 5 , [1] = 1 , [4] = 4 , [2] = 2 }

Currently, this *is* a valid sequence.  Under this proposal, this
construction could be problematic.  You *could* attempt to calculate the
length by falling back on the O(ln) method, but there are *always*
pathological cases to consider:

        t = { 1 , 2 , 3 , 4 , 5 }
        t[7] = 7 -- #t still 5
        t[6] = 6 -- shoult #t be 7 now?

  Would this even be a real problem?  I think this proposal would easily fix
80-90% of the issues with storing nils in sequences, but the corner cases
will probably go up.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Philipp Janda
In reply to this post by Dirk Laurie-2
Am 16.03.2018 um 12:31 schröbte Dirk Laurie:

> Define a "strong table" as one in which 't[k]=nil' does not remove the
> key, it stores nil.
>
> In Lua 5.4 (work1), all or no tables are strong, depending on
> LUA_NILINTABLE. A new keyword 'undef' is needed to remove a key from a
> strong table.
>
> If instead of that, a hitherto unused letter of the __mode metafield
> (say 'n') is used to indicate whether a table is strong, then
> (a) strong and non-strong tables could coexist in the same code;
> (b) no compiler variable would be needed
>
> To remove a key from a strong table, a function table.undef could be
> supplied that temporarily replaces 'n' in __mode by a neutral letter
> and does a rawset.

This would make code that is always wrong (leaks table keys) in 5.4work1
only sometimes wrong with "strong" tables. I'm not sure that is better,
because you'd have to fix it either way, and you would have less
pressure to do so.

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.


Philipp




Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Italo Maia
Wild idea: lua adds array/list datatype. Goes well with the lua 6.0 suggestion (and some others) and no need to change the table+nil behavior.

2018-03-17 3:32 GMT-03:00 Philipp Janda <[hidden email]>:
Am 16.03.2018 um 12:31 schröbte Dirk Laurie:

Define a "strong table" as one in which 't[k]=nil' does not remove the
key, it stores nil.

In Lua 5.4 (work1), all or no tables are strong, depending on
LUA_NILINTABLE. A new keyword 'undef' is needed to remove a key from a
strong table.

If instead of that, a hitherto unused letter of the __mode metafield
(say 'n') is used to indicate whether a table is strong, then
(a) strong and non-strong tables could coexist in the same code;
(b) no compiler variable would be needed

To remove a key from a strong table, a function table.undef could be
supplied that temporarily replaces 'n' in __mode by a neutral letter
and does a rawset.

This would make code that is always wrong (leaks table keys) in 5.4work1 only sometimes wrong with "strong" tables. I'm not sure that is better, because you'd have to fix it either way, and you would have less pressure to do so.

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.


Philipp







--
"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
===========================
Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Coda Highland
In reply to this post by Sean Conner


On Mar 16, 2018 4:05 PM, "Sean Conner" <[hidden email]> wrote:

  The problem of "storing" nils in tables deals exclusively with sequences.

No, it also affects serialization and integration. The whole reason this came up is because sometimes you need to distinguish between "present and no value" and "not present at all". Sequences are a very obvious (and very noisily discussed) case of this with additional implications, and you can work around some of the remainder with a singleton NULL={}, but it's not ideal.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Thomas Jericke
In reply to this post by Philipp Janda
On 17.03.2018 07:32, Philipp Janda wrote:
Am 16.03.2018 um 12:31 schröbte Dirk Laurie:
Define a "strong table" as one in which 't[k]=nil' does not remove the
key, it stores nil.

In Lua 5.4 (work1), all or no tables are strong, depending on
LUA_NILINTABLE. A new keyword 'undef' is needed to remove a key from a
strong table.

If instead of that, a hitherto unused letter of the __mode metafield
(say 'n') is used to indicate whether a table is strong, then
(a) strong and non-strong tables could coexist in the same code;
(b) no compiler variable would be needed

To remove a key from a strong table, a function table.undef could be
supplied that temporarily replaces 'n' in __mode by a neutral letter
and does a rawset.

This would make code that is always wrong (leaks table keys) in 5.4work1 only sometimes wrong with "strong" tables. I'm not sure that is better, because you'd have to fix it either way, and you would have less pressure to do so.
I don't see how this is a problem, as long as you need to need to set the mode of the table explicitly. Therefore this is surely new code, and of there is a leak in it, it is a mistake not a backwards compatibility problem. Of course you may not pass a strong table to old libraries.
If you want to write backwards compatible code, just don't use the feature at all or make a version check.
--
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Hisham
In reply to this post by Philipp Janda
On 17 March 2018 at 03:32, Philipp Janda <[hidden email]> 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 `t[k] = f()` of every module and dependency (and their
dependencies recursively) would have to be checked for memory leaks.
And this won't be the typical Lua 5.x to Lua 5.(x+1) situation where
you try out a dependency on a new Lua version and it doesn't build
because lua_dump now has an extra argument, or lua_objlen was renamed
to lua_rawlen in a Lua/C module, or you get a crash with a stack trace
in your testsuite because setfenv() doesn't exist anymore. Patches to
add Lua 5.(x+1) support in a module are typically small and easy to
write.

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
   * the entire existing Lua 5.x ecosystem will not embrace the bridge
   * the parts of the ecosystem that do will not do so at the same time
   * this will bring major grief to users

In light of this, breaking the _existing_ syntax would be _helpful_ to
ensure things are not silently broken by default.

Let's be honest: Lua's 5.x ecosystem is small and fragmented, compared
to other languages. There's the LuaJIT situation, which, even if you
choose to ignore it and consider it a different language, affects the
way developers mantain code for Lua. Developers invested in a
particular Lua 5.x version or LuaJIT will support Lua 5.y > 5.x _if
it's not too much work_ (I've heard that from people many times). They
will not audit their entire codebase and dependencies for every usage
of nil just for Lua 6's sake. Lua 5.x will stick around for a long
time, and it is what it is, kind of like ANSI C (89). However,  Lua is
in a unique position as an embedded language, and has many ecosystems,
not one. That is, many projects adopting Lua completely disregard the
existing ecosystem(s) around it. Many new projects will have no
problem adopting Lua 6. This is not a Perl 5 vs 6 situation, or a
Python 2 vs 3 one.

Will a Lua 6 (with no attempted "path-for-compatibility") weaken Lua's
already fragile Lua 5.x ecosystem, which I worked so hard on to
promote via LuaRocks for so many years? Yes. But again, it is what it
is. That ship has sailed: the Lua 5.x ecosystem is already de facto
tied to the success of Lua 5.1 and LuaJIT -- the number of Lua
5.(x>1)-only modules is tiny (only 4.8% of LuaRocks modules marked as
5.3-compatible are not marked 5.1-compatible). Lua 5.x keeps getting
better and better, but most of us never get the chance to use a lot of
the good stuff in production because we're tied to Lua 5.1.

We have a chance to do better with the Lua 6 ecosystem, without
injecting the Lua 5.x ecosystem into it in a "silently broken by
default" state. That is, if we care about an ecosystem at all. And if
we don't, breaking compatibility and making a better language without
the clever hacks is a no-brainer anyway.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Dirk Laurie-2
2018-03-19 18:16 GMT+02:00 Hisham <[hidden email]>:

> On 17 March 2018 at 03:32, Philipp Janda <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Italo Maia
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 <[hidden email]>:
2018-03-19 18:16 GMT+02:00 Hisham <[hidden email]>:
> On 17 March 2018 at 03:32, Philipp Janda <[hidden email]> 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
===========================
Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Roberto Ierusalimschy
In reply to this post by Hisham
> Every `t[k] = f()` of every module and dependency (and their
> dependencies recursively) would have to be checked for memory leaks.
> And this won't be the typical Lua 5.x to Lua 5.(x+1) situation where
> you try out a dependency on a new Lua version and it doesn't) build
> because lua_dump now has an extra argument, or lua_objlen was renamed
> to lua_rawlen in a Lua/C module, or you get a crash with a stack trace
> in your testsuite because setfenv() doesn't exist anymore.

I still think you are exaggerating the problem, but I may be wrong. I
would like to know how many real programs have the construction
t[k] = f() where f() returning 'nil' is not a bug. (You mentioned
that table.move could create that kind of thing. I asked for a real
scenario, but got no answer.)

More concretely, I propose a little experiment: suppose that Lua raises
a run-time error for every assignment of nils to tables except in
explicit assignments with a constant nil (t[k]=nil). How frequently this
error will occurr without hinting a hidden bug in the code? (Please,
any answer should be about some piece of real, useful code where that
could happen.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Dirk Laurie-2
2018-03-19 21:08 GMT+02:00 Roberto Ierusalimschy <[hidden email]>:

> More concretely, I propose a little experiment: suppose that Lua raises
> a run-time error for every assignment of nils to tables except in
> explicit assignments with a constant nil (t[k]=nil). How frequently this
> error will occurr without hinting a hidden bug in the code?

Including, of course, var=uninit where "var" is global and "uninit" is
an uninitialized global?

My first reaction was that it occurs often, but then I realized that
the cases where I would do that, the target would be an upvalue or a
local — if it is a global, it is likely to be a typo.

Yes! Give us that error!

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Dibyendu Majumdar
In reply to this post by Roberto Ierusalimschy
On 19 March 2018 at 19:08, Roberto Ierusalimschy <[hidden email]> wrote:
>> Every `t[k] = f()` of every module and dependency (and their
>> dependencies recursively) would have to be checked for memory leaks.
>> And this won't be the typical Lua 5.x to Lua 5.(x+1) situation where
>> you try out a dependency on a new Lua version and it doesn't) build
>> because lua_dump now has an extra argument, or lua_objlen was renamed
>> to lua_rawlen in a Lua/C module, or you get a crash with a stack trace
>> in your testsuite because setfenv() doesn't exist anymore.
>
> I still think you are exaggerating the problem, but I may be wrong.

I think the problem Hisham is referring to is quite obvious (or maybe
not as I missed it too)?

t = {1,2, nil, 3}
for k,v in pairs(t) do
 print(k,v)
end

Isn't the issue that existing code does not expect nil to appear while
iterating?

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Dibyendu Majumdar
In reply to this post by Hisham
On 19 March 2018 at 16:16, Hisham <[hidden email]> wrote:

> On 17 March 2018 at 03:32, Philipp Janda <[hidden email]> 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.
>
> 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
>    * the entire existing Lua 5.x ecosystem will not embrace the bridge
>    * the parts of the ecosystem that do will not do so at the same time
>    * this will bring major grief to users
>

Hi Hisham,

As always you have deep insight into compatibility issues no doubt due
to your experience with LuaRocks. Thank you - you have saved me a lot
of useless effort as I can see now why my idea of a generic array
sub-type is a non-starter from the point of view of compatibility with
existing code.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Gregg Reynolds-2
In reply to this post by Dirk Laurie-2


On Fri, Mar 16, 2018, 6:31 AM Dirk Laurie <[hidden email]> wrote:
Define a "strong table" as one in which 't[k]=nil' does not remove the
key, it stores nil.

Result: two types of tables. Bad idea.

Non sunt multiplicanda entia sine necessitate

(Occam's razor)

Gregg
Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Tomás Guisasola-2
In reply to this post by Dirk Laurie-2
Hi

2018-03-19 16:28 GMT-03:00 Dirk Laurie <[hidden email]>:
2018-03-19 21:08 GMT+02:00 Roberto Ierusalimschy <[hidden email]>:

> More concretely, I propose a little experiment: suppose that Lua raises
> a run-time error for every assignment of nils to tables except in
> explicit assignments with a constant nil (t[k]=nil). How frequently this
> error will occurr without hinting a hidden bug in the code?

Including, of course, var=uninit where "var" is global and "uninit" is
an uninitialized global?

My first reaction was that it occurs often, but then I realized that
the cases where I would do that, the target would be an upvalue or a
local — if it is a global, it is likely to be a typo.

Yes! Give us that error
I do have cases where there are correct assignments of nil to table entries (to allow optional parameters to functions with named arguments), but I think it is worth a try.  I would gladly adapt the code to t[k] = optional or nil (or an if-then if necessary).

Give us that error!

Regards,
Tomás
Reply | Threaded
Open this post in threaded view
|

Re: Strong tables in Lua 5.4

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:

> > Every `t[k] = f()` of every module and dependency (and their
> > dependencies recursively) would have to be checked for memory leaks.
> > And this won't be the typical Lua 5.x to Lua 5.(x+1) situation where
> > you try out a dependency on a new Lua version and it doesn't) build
> > because lua_dump now has an extra argument, or lua_objlen was renamed
> > to lua_rawlen in a Lua/C module, or you get a crash with a stack trace
> > in your testsuite because setfenv() doesn't exist anymore.
>
> I still think you are exaggerating the problem, but I may be wrong. I
> would like to know how many real programs have the construction
> t[k] = f() where f() returning 'nil' is not a bug. (You mentioned
> that table.move could create that kind of thing. I asked for a real
> scenario, but got no answer.)
>
> More concretely, I propose a little experiment: suppose that Lua raises
> a run-time error for every assignment of nils to tables except in
> explicit assignments with a constant nil (t[k]=nil). How frequently this
> error will occurr without hinting a hidden bug in the code? (Please,
> any answer should be about some piece of real, useful code where that
> could happen.)

  Less than a minute in, and I found a place what would break code I've
written (for work no less!).

  I have the following function:

        -- Okay, we store a coutine and arguments into a table for later
        -- running the it.

        function schedule(co,...)
          RQUEUE[#RQUEUE + 1] = { co, ... }
        end

then later down in the code I have the following:

        -- We've timed out on waiting for something.  signal the error by
        -- returning nil and and error of TIMEDOUT

        schedule(obj.co,nil,errno.ETIMEDOUT)

  -spc

123