[ 5.4 ] Sequence Iteration - Knowing when to Stop?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[ 5.4 ] Sequence Iteration - Knowing when to Stop?

ThePhD
I have a bit of a question. I'm updating some C API code to handle "LUA_NILINTABLES". I created a faux-table with some nil's and some values interspersed, and I noticed that when I iterate over the table and "walk off the end", all functions like `lua_geti` tell me is that I have more Nils.

I have so far successfully avoided calling rawlen / the length operator to count the number in a sequence from the C API. What do I do to know if I'm at the end of a sequence in Lua 5.4 with "LUA_NILINTABLES"? Am I missing an API function added to 5.4-work1's manual for this?
Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Andrew Gierth
>>>>> "ThePhD" == ThePhD  <[hidden email]> writes:

 ThePhD> I have so far successfully avoided calling rawlen / the length
 ThePhD> operator to count the number in a sequence from the C API. What
 ThePhD> do I do to know if I'm at the end of a sequence in Lua 5.4 with
 ThePhD> "LUA_NILINTABLES"? Am I missing an API function added to
 ThePhD> 5.4-work1's manual for this?

The new functions lua_keyin and lua_removekey seem not to be documented
in the manual, probably on account of the fact that NILINTABLES is still
a purely experimental feature and not going to be enabled by default,
and therefore the API for extra functions to handle it is presumably not
yet nailed down.

I notice that lua_keyin and lua_removekey both call metamethods, and I
don't see any "raw" equivalent; that could be a serious problem.

(It's obviously important that these APIs _do_ get nailed down and
documented even if NILINTABLES remains off by default)

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

ThePhD
Thanks for the heads up Andrew. I managed to get it to work using `lua_keyin`.

As a side note, I will point out that if this is the direction the Lua team is taking, it might be prudent to reduce the amount of function calls and repeat-work that comes from searching for a key + getting its value. A function such as

     int lua_keyvalue(lua_State* int index);

would be great (though the name needs to be properly bikeshed). The desire to push the value of the key if the key is present and return non-zero: otherwise, return 0 and push nothing. This would prevent having to perform a double lookup from doing lua_keyin + lua_geti/lua_getfield/lua_gettable. This does not mean `lua_keyin` should not exist; having both would be critical to making sure the minimal amount of overhead is performed for the desired operation (checking if something exists versus knowing you are going to operate on it if it does exist).

     Just musings, but... I hope they get in, and I hope that `lua_keyin` as well as the potential hypothetical `lua_keyvalue` include versions that get integers and fields for number / string arguments directly (as well as their raw version), making for a full suite that allows maximum performance and mimics the current Lua C API structure:

     lua_keyin(L, index); lua_keyin_i(L, index, integer); lua_keyin_field(L, index, "string");
     lua_keyvalue(L, index);  lua_keyvalue_i(L, index, integer); lua_keyvalue_field(L, index, "string");



On Mon, May 28, 2018 at 2:05 PM, Andrew Gierth <[hidden email]> wrote:
>>>>> "ThePhD" == ThePhD  <[hidden email]> writes:

 ThePhD> I have so far successfully avoided calling rawlen / the length
 ThePhD> operator to count the number in a sequence from the C API. What
 ThePhD> do I do to know if I'm at the end of a sequence in Lua 5.4 with
 ThePhD> "LUA_NILINTABLES"? Am I missing an API function added to
 ThePhD> 5.4-work1's manual for this?

The new functions lua_keyin and lua_removekey seem not to be documented
in the manual, probably on account of the fact that NILINTABLES is still
a purely experimental feature and not going to be enabled by default,
and therefore the API for extra functions to handle it is presumably not
yet nailed down.

I notice that lua_keyin and lua_removekey both call metamethods, and I
don't see any "raw" equivalent; that could be a serious problem.

(It's obviously important that these APIs _do_ get nailed down and
documented even if NILINTABLES remains off by default)

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Roberto Ierusalimschy
>      Just musings, but... I hope they get in, and I hope that `lua_keyin`
> as well as the potential hypothetical `lua_keyvalue` include versions that
> get integers and fields for number / string arguments directly (as well as
> their raw version), making for a full suite that allows maximum performance
> and mimics the current Lua C API structure:
>
>      [...]

We have decided that, at least for 5.4, we are not going on with
the nils-in-table proposal. Although we really like the idea, the
compatibility problems seem too big. As this message evidentiates again,
the language would need a lot of extra stuff (metamethods, API calls,
etc.), even when the option is off.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Russell Haley


On Tue, May 29, 2018 at 9:53 AM, Roberto Ierusalimschy <[hidden email]> wrote:
>      Just musings, but... I hope they get in, and I hope that `lua_keyin`
> as well as the potential hypothetical `lua_keyvalue` include versions that
> get integers and fields for number / string arguments directly (as well as
> their raw version), making for a full suite that allows maximum performance
> and mimics the current Lua C API structure:
>
>      [...]

We have decided that, at least for 5.4, we are not going on with
the nils-in-table proposal. Although we really like the idea, the
compatibility problems seem too big. As this message evidentiates again,
the language would need a lot of extra stuff (metamethods, API calls,
etc.), even when the option is off.

-- Roberto

: - (

That's too bad.  The behavior of holes in tables was a huge block for me when I started using Lua (and is still a pain in the ass IMO). I think allowing nil in tables removes a hole in the language (pun intended) and makes tables jmore friendly for newcomers and more practical for using as a sequence. Are we going to have to wait another 4 years for you to tease us with the possibility again?

This is very disappointing news. (To be clear, the news disappoints me, not the people or the language. No flaming necessary).
Russ 

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Dirk Laurie-2
2018-05-29 20:32 GMT+02:00 Russell Haley <[hidden email]>:

>
>
> On Tue, May 29, 2018 at 9:53 AM, Roberto Ierusalimschy
> <[hidden email]> wrote:
>>
>> >      Just musings, but... I hope they get in, and I hope that
>> > `lua_keyin`
>> > as well as the potential hypothetical `lua_keyvalue` include versions
>> > that
>> > get integers and fields for number / string arguments directly (as well
>> > as
>> > their raw version), making for a full suite that allows maximum
>> > performance
>> > and mimics the current Lua C API structure:
>> >
>> >      [...]
>>
>> We have decided that, at least for 5.4, we are not going on with
>> the nils-in-table proposal. Although we really like the idea, the
>> compatibility problems seem too big. As this message evidentiates again,
>> the language would need a lot of extra stuff (metamethods, API calls,
>> etc.), even when the option is off.
>>
>> -- Roberto
>>
> : - (
>
> That's too bad.  The behavior of holes in tables was a huge block for me
> when I started using Lua (and is still a pain in the ass IMO). I think
> allowing nil in tables removes a hole in the language (pun intended) and
> makes tables jmore friendly for newcomers and more practical for using as a
> sequence. Are we going to have to wait another 4 years for you to tease us
> with the possibility again?
>
> This is very disappointing news. (To be clear, the news disappoints me, not
> the people or the language. No flaming necessary).

Nils in tables will be very counterintuitive for people who for
several years have used mainly Lua. (It may be OK for some people
still used to what their previous language did.)

Some years ago, I had this bright idea. Self-initializing tables. The
first time you access tbl[i], the __index metamethod would kick in and
construct the object. Items you never access need never be
initialized. Brilliant.

Until a table in which I had initialized everything was used in `for
k,v in ipairs(tbl) do`. Work out what happened. It was painful.

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Soni "They/Them" L.


On 2018-05-29 03:58 PM, Dirk Laurie wrote:

> 2018-05-29 20:32 GMT+02:00 Russell Haley <[hidden email]>:
>>
>> On Tue, May 29, 2018 at 9:53 AM, Roberto Ierusalimschy
>> <[hidden email]> wrote:
>>>>       Just musings, but... I hope they get in, and I hope that
>>>> `lua_keyin`
>>>> as well as the potential hypothetical `lua_keyvalue` include versions
>>>> that
>>>> get integers and fields for number / string arguments directly (as well
>>>> as
>>>> their raw version), making for a full suite that allows maximum
>>>> performance
>>>> and mimics the current Lua C API structure:
>>>>
>>>>       [...]
>>> We have decided that, at least for 5.4, we are not going on with
>>> the nils-in-table proposal. Although we really like the idea, the
>>> compatibility problems seem too big. As this message evidentiates again,
>>> the language would need a lot of extra stuff (metamethods, API calls,
>>> etc.), even when the option is off.
>>>
>>> -- Roberto
>>>
>> : - (
>>
>> That's too bad.  The behavior of holes in tables was a huge block for me
>> when I started using Lua (and is still a pain in the ass IMO). I think
>> allowing nil in tables removes a hole in the language (pun intended) and
>> makes tables jmore friendly for newcomers and more practical for using as a
>> sequence. Are we going to have to wait another 4 years for you to tease us
>> with the possibility again?
>>
>> This is very disappointing news. (To be clear, the news disappoints me, not
>> the people or the language. No flaming necessary).
> Nils in tables will be very counterintuitive for people who for
> several years have used mainly Lua. (It may be OK for some people
> still used to what their previous language did.)
>
> Some years ago, I had this bright idea. Self-initializing tables. The
> first time you access tbl[i], the __index metamethod would kick in and
> construct the object. Items you never access need never be
> initialized. Brilliant.
>
> Until a table in which I had initialized everything was used in `for
> k,v in ipairs(tbl) do`. Work out what happened. It was painful.
>

It initialized everything, in order, one by one, using a very slow
integer factorization algorithm?

Or was this pre-Lua 5.3?

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


Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Dirk Laurie-2
What happened when it reached the end of the list?

2018-05-29 21:06 GMT+02:00 Soni "They/Them" L. <[hidden email]>:

>
>
> On 2018-05-29 03:58 PM, Dirk Laurie wrote:
>>
>> 2018-05-29 20:32 GMT+02:00 Russell Haley <[hidden email]>:
>>>
>>>
>>> On Tue, May 29, 2018 at 9:53 AM, Roberto Ierusalimschy
>>> <[hidden email]> wrote:
>>>>>
>>>>>       Just musings, but... I hope they get in, and I hope that
>>>>> `lua_keyin`
>>>>> as well as the potential hypothetical `lua_keyvalue` include versions
>>>>> that
>>>>> get integers and fields for number / string arguments directly (as well
>>>>> as
>>>>> their raw version), making for a full suite that allows maximum
>>>>> performance
>>>>> and mimics the current Lua C API structure:
>>>>>
>>>>>       [...]
>>>>
>>>> We have decided that, at least for 5.4, we are not going on with
>>>> the nils-in-table proposal. Although we really like the idea, the
>>>> compatibility problems seem too big. As this message evidentiates again,
>>>> the language would need a lot of extra stuff (metamethods, API calls,
>>>> etc.), even when the option is off.
>>>>
>>>> -- Roberto
>>>>
>>> : - (
>>>
>>> That's too bad.  The behavior of holes in tables was a huge block for me
>>> when I started using Lua (and is still a pain in the ass IMO). I think
>>> allowing nil in tables removes a hole in the language (pun intended) and
>>> makes tables jmore friendly for newcomers and more practical for using as
>>> a
>>> sequence. Are we going to have to wait another 4 years for you to tease
>>> us
>>> with the possibility again?
>>>
>>> This is very disappointing news. (To be clear, the news disappoints me,
>>> not
>>> the people or the language. No flaming necessary).
>>
>> Nils in tables will be very counterintuitive for people who for
>> several years have used mainly Lua. (It may be OK for some people
>> still used to what their previous language did.)
>>
>> Some years ago, I had this bright idea. Self-initializing tables. The
>> first time you access tbl[i], the __index metamethod would kick in and
>> construct the object. Items you never access need never be
>> initialized. Brilliant.
>>
>> Until a table in which I had initialized everything was used in `for
>> k,v in ipairs(tbl) do`. Work out what happened. It was painful.
>>
>
> It initialized everything, in order, one by one, using a very slow integer
> factorization algorithm?
>
> Or was this pre-Lua 5.3?
>
> --
> 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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Soni "They/Them" L.


On 2018-05-29 04:15 PM, Dirk Laurie wrote:
> What happened when it reached the end of the list?

What end of the list?

>
> 2018-05-29 21:06 GMT+02:00 Soni "They/Them" L. <[hidden email]>:
>>
>> On 2018-05-29 03:58 PM, Dirk Laurie wrote:
>>> 2018-05-29 20:32 GMT+02:00 Russell Haley <[hidden email]>:
>>>>
>>>> On Tue, May 29, 2018 at 9:53 AM, Roberto Ierusalimschy
>>>> <[hidden email]> wrote:
>>>>>>        Just musings, but... I hope they get in, and I hope that
>>>>>> `lua_keyin`
>>>>>> as well as the potential hypothetical `lua_keyvalue` include versions
>>>>>> that
>>>>>> get integers and fields for number / string arguments directly (as well
>>>>>> as
>>>>>> their raw version), making for a full suite that allows maximum
>>>>>> performance
>>>>>> and mimics the current Lua C API structure:
>>>>>>
>>>>>>        [...]
>>>>> We have decided that, at least for 5.4, we are not going on with
>>>>> the nils-in-table proposal. Although we really like the idea, the
>>>>> compatibility problems seem too big. As this message evidentiates again,
>>>>> the language would need a lot of extra stuff (metamethods, API calls,
>>>>> etc.), even when the option is off.
>>>>>
>>>>> -- Roberto
>>>>>
>>>> : - (
>>>>
>>>> That's too bad.  The behavior of holes in tables was a huge block for me
>>>> when I started using Lua (and is still a pain in the ass IMO). I think
>>>> allowing nil in tables removes a hole in the language (pun intended) and
>>>> makes tables jmore friendly for newcomers and more practical for using as
>>>> a
>>>> sequence. Are we going to have to wait another 4 years for you to tease
>>>> us
>>>> with the possibility again?
>>>>
>>>> This is very disappointing news. (To be clear, the news disappoints me,
>>>> not
>>>> the people or the language. No flaming necessary).
>>> Nils in tables will be very counterintuitive for people who for
>>> several years have used mainly Lua. (It may be OK for some people
>>> still used to what their previous language did.)
>>>
>>> Some years ago, I had this bright idea. Self-initializing tables. The
>>> first time you access tbl[i], the __index metamethod would kick in and
>>> construct the object. Items you never access need never be
>>> initialized. Brilliant.
>>>
>>> Until a table in which I had initialized everything was used in `for
>>> k,v in ipairs(tbl) do`. Work out what happened. It was painful.
>>>
>> It initialized everything, in order, one by one, using a very slow integer
>> factorization algorithm?
>>
>> Or was this pre-Lua 5.3?
>>
>> --
>> 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.
>>
>>

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


Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Dirk Laurie-2
2018-05-30 0:02 GMT+02:00 Soni "They/Them" L. <[hidden email]>:

> On 2018-05-29 04:15 PM, Dirk Laurie wrote:
>>
>> What happened when it reached the end of the list?
>
> What end of the list?

Exactly.

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

ThePhD
It is a little unfortunate to hear that; I was excited as this fixed a lot of problems with equating `nullptr` and `NULL` in C++ and C in container types. In my humble opinion, the _current_ behavior was always counter intuitive to me and always took me some time to struggle with and I always -- always -- have to keep explaining it to newcomers and other people, C++ pointers or not thrown into the mix.

Hopefully in the future we can get nil-in-tables (and maybe even the native array subtype for tables?!). I'll keep my eye out for it, and appreciate the experiment at least being brought forward!

Best of luck for Lua 5.4. :D


On Wed, May 30, 2018 at 12:30 AM, Dirk Laurie <[hidden email]> wrote:
2018-05-30 0:02 GMT+02:00 Soni "They/Them" L. <[hidden email]>:

> On 2018-05-29 04:15 PM, Dirk Laurie wrote:
>>
>> What happened when it reached the end of the list?
>
> What end of the list?

Exactly.


Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Thijs Schreijer
In reply to this post by Roberto Ierusalimschy


> On 29 May 2018, at 18:53, Roberto Ierusalimschy <[hidden email]> wrote:
>
>>     Just musings, but... I hope they get in, and I hope that `lua_keyin`
>> as well as the potential hypothetical `lua_keyvalue` include versions that
>> get integers and fields for number / string arguments directly (as well as
>> their raw version), making for a full suite that allows maximum performance
>> and mimics the current Lua C API structure:
>>
>>     [...]
>
> We have decided that, at least for 5.4, we are not going on with
> the nils-in-table proposal. Although we really like the idea, the
> compatibility problems seem too big. As this message evidentiates again,
> the language would need a lot of extra stuff (metamethods, API calls,
> etc.), even when the option is off.
>
> -- Roberto
>

Despite the disappointed reactions on the above message so far, I for one couldn’t care less. In 10+ years of using Lua I got bitten only once by a bug because of a nil-in-table. How awkward it initially may be, once you get used to it, you hardly ever need nil-in-table constructs anyway, and in those few cases it is easy to work around.

Imho the only thing it will fix is “initial expectations of newcomers”. And since that will always be a one-off cost, it is not worth the recurring costs (performance/runtime costs).

Thijs
Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Javier Guerra Giraldez


On 1 June 2018 at 14:21, Thijs Schreijer <[hidden email]> wrote:
Despite the disappointed reactions on the above message so far, I for one couldn’t care less.

I'm roughly on the same place.  i find #t perfectly predictable: #t+1 is nil and #t is either occupied, or zero.  that's all.  all the talk about "you never know if a table is a valid sequence unless you generate it yourself!".... is just like dynamic types, you either write defensive code (check everything), or write pretty code and blame any error on the caller.



--
Javier
Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Russell Haley
In reply to this post by Thijs Schreijer


On Fri, Jun 1, 2018 at 6:21 AM, Thijs Schreijer <[hidden email]> wrote:


> On 29 May 2018, at 18:53, Roberto Ierusalimschy <[hidden email]> wrote:
>
>>     Just musings, but... I hope they get in, and I hope that `lua_keyin`
>> as well as the potential hypothetical `lua_keyvalue` include versions that
>> get integers and fields for number / string arguments directly (as well as
>> their raw version), making for a full suite that allows maximum performance
>> and mimics the current Lua C API structure:
>>
>>     [...]
>
> We have decided that, at least for 5.4, we are not going on with
> the nils-in-table proposal. Although we really like the idea, the
> compatibility problems seem too big. As this message evidentiates again,
> the language would need a lot of extra stuff (metamethods, API calls,
> etc.), even when the option is off.
>
> -- Roberto
>

Despite the disappointed reactions on the above message so far, I for one couldn’t care less. In 10+ years of using Lua I got bitten only once by a bug because of a nil-in-table. How awkward it initially may be, once you get used to it, you hardly ever need nil-in-table constructs anyway, and in those few cases it is easy to work around.

Imho the only thing it will fix is “initial expectations of newcomers”. And since that will always be a one-off cost, it is not worth the recurring costs (performance/runtime costs).

Thijs

Well I've been at this for three years now and it's still a PIA for me and all the people that want to see an array data type. I *hate* having to use arrays in JavaScript, but I guess I'll have to throw my hat in that ring. NIL_IN_TABLE seems like a pretty minor compromise for allowing predictable sequences. 

Russ
Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

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

>
> > On 29 May 2018, at 18:53, Roberto Ierusalimschy <[hidden email]> wrote:
> >
> >>     Just musings, but... I hope they get in, and I hope that `lua_keyin`
> >> as well as the potential hypothetical `lua_keyvalue` include versions that
> >> get integers and fields for number / string arguments directly (as well as
> >> their raw version), making for a full suite that allows maximum performance
> >> and mimics the current Lua C API structure:
> >>
> >>     [...]
> >
> > We have decided that, at least for 5.4, we are not going on with
> > the nils-in-table proposal. Although we really like the idea, the
> > compatibility problems seem too big. As this message evidentiates again,
> > the language would need a lot of extra stuff (metamethods, API calls,
> > etc.), even when the option is off.
>
> Despite the disappointed reactions on the above message so far, I for one
> couldn’t care less. In 10+ years of using Lua I got bitten only once by a
> bug because of a nil-in-table. How awkward it initially may be, once you
> get used to it, you hardly ever need nil-in-table constructs anyway, and
> in those few cases it is easy to work around.

  In the 9 years I've been using Lua, a nil-in-table has only bitten me once
(and not even then because it miraculously worked!) which was an easy fix on
my part---replace nil with false (and because I was using 'not foo[idx]' for
checking, even less code had to change).

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Dirk Laurie-2
In reply to this post by Russell Haley
2018-06-01 17:56 GMT+02:00 Russell Haley <[hidden email]>:

> Well I've been at this for three years now and it's still a PIA for me and
> all the people that want to see an array data type. I *hate* having to use
> arrays in JavaScript, but I guess I'll have to throw my hat in that ring.
> NIL_IN_TABLE seems like a pretty minor compromise for allowing predictable
> sequences.

I've been in Lua, coming from Python, but further back from Pascal,
for seven years. The first two of them I spent lamenting the Python
data structures missing from Lua (i.e. lists, arrays and tuples, Lua
seemed to have only dictionaries). At the same time I gradually
mastered the more advanced features of Lua: metatables, generic
`for`, coroutines. Nowadays, I think in Lua.

On the rare occasions that I can't avoid writing Python, I spend half
of my time in the interactive help and the other half cursing the
non-equivalence of the invisible difference between a tab
and four spaces.

There is nothing involving arrays that you can't do with metatables
except write a table literal that will automatically imply a metatable.
Nobody compels you to use the table library. I have a whole file
of specialized tables: deque, stack, queue, list. An array is just
a special case of a deque, where upper and lower bounds are
variable.

But speaking of the table library: I wonder how many people are
using the very powerful 5.3 table.move. And how many people
have noticed the trivial implementation of nil-impervious
table.insert and table.remove that is possible with table.move.

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

ThePhD
It's less of a problem when you write in purely Lua and extremely easy to work around, I agree.

In C++ it's a semi-regular thorn that reminds me when I spend too much time away from Lua. If I'm building something type-safe on top of Lua, using `false` to signal `nil` or similar does not exactly work properly. It's not impossible to work around, but convincing someone that serializing `nullptr` from C or C++ as `false`, some library-specific `USERDATA_NIL` (which is even harder to implement under 5.1 and 5.2 userdata comparison rules from metatable equality constraints), or other is an extremely hard sell. It's also even harder when someone places `nil` in a table that's expected to be a sequence and try to get that sequence out as, say, a `std::vector<my_type*>`. It just doesn't line up proper a lot with the types...

(Consequently, this is another reason why strict type safety is entirely optional in my opinion when building these things, which has earned me some grilling from colleagues before, but...)


On Fri, Jun 1, 2018 at 3:30 PM, Dirk Laurie <[hidden email]> wrote:
2018-06-01 17:56 GMT+02:00 Russell Haley <[hidden email]>:

> Well I've been at this for three years now and it's still a PIA for me and
> all the people that want to see an array data type. I *hate* having to use
> arrays in JavaScript, but I guess I'll have to throw my hat in that ring.
> NIL_IN_TABLE seems like a pretty minor compromise for allowing predictable
> sequences.

I've been in Lua, coming from Python, but further back from Pascal,
for seven years. The first two of them I spent lamenting the Python
data structures missing from Lua (i.e. lists, arrays and tuples, Lua
seemed to have only dictionaries). At the same time I gradually
mastered the more advanced features of Lua: metatables, generic
`for`, coroutines. Nowadays, I think in Lua.

On the rare occasions that I can't avoid writing Python, I spend half
of my time in the interactive help and the other half cursing the
non-equivalence of the invisible difference between a tab
and four spaces.

There is nothing involving arrays that you can't do with metatables
except write a table literal that will automatically imply a metatable.
Nobody compels you to use the table library. I have a whole file
of specialized tables: deque, stack, queue, list. An array is just
a special case of a deque, where upper and lower bounds are
variable.

But speaking of the table library: I wonder how many people are
using the very powerful 5.3 table.move. And how many people
have noticed the trivial implementation of nil-impervious
table.insert and table.remove that is possible with table.move.


Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Duane Leslie
In reply to this post by ThePhD
On 1 Jun 2018, at 23:32, Javier Guerra Giraldez <[hidden email]> wrote:

On 1 June 2018 at 14:21, Thijs Schreijer <[hidden email]> wrote:
Despite the disappointed reactions on the above message so far, I for one couldn’t care less.

I'm roughly on the same place.

I agree with this for tables in general too, but I can see the value in one of the initial motivations which I believe was to have a reliable arguments object rather than the magical `...` syntax entity.  Solving this with an immutable tuple is the best path forward in my opinion, and something I'd quite like to see, but the issue of tuple equality and hashability is not trivial to solve (although related, and could probably use a variant of the string interning behaviour).  If I ever find a week with nothing to do I might try to implement it.

Regards,

Duane.
Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Dirk Laurie-2
2018-06-02 0:27 GMT+02:00 Duane Leslie <[hidden email]>:

> I agree with this for tables in general too, but I can see the value in one
> of the initial motivations which I believe was to have a reliable arguments
> object rather than the magical `...` syntax entity.

All that the ... syntax does is to bring into the open the fact that such
an object entails overheads, and to offer the user the choice whether to
construct it with {...} or table.pack(...) or not at all, using the admittedly
ugly select(arg,...) mechanism (which looks as if it entails even worse
overheads, but actually is quite efficient).

> Solving this with an immutable tuple is the best path forward in my opinion,
> and something I'd quite like to see, but the issue of tuple equality and
> hashability is not trivial to solve (although related, and could probably
> use a variant of the string interning behaviour).  If I ever find a week
> with nothing to do I might try to implement it.

Not a week: an hour will suffice in Lua 5.3 as long as you restrict the
atoms to things that string.pack can handle. (They have to be restricted
to immutable things anyway.)

Reply | Threaded
Open this post in threaded view
|

Re: [ 5.4 ] Sequence Iteration - Knowing when to Stop?

Hisham
In reply to this post by Roberto Ierusalimschy
On 29 May 2018 at 13:53, Roberto Ierusalimschy <[hidden email]> wrote:

>>      Just musings, but... I hope they get in, and I hope that `lua_keyin`
>> as well as the potential hypothetical `lua_keyvalue` include versions that
>> get integers and fields for number / string arguments directly (as well as
>> their raw version), making for a full suite that allows maximum performance
>> and mimics the current Lua C API structure:
>>
>>      [...]
>
> We have decided that, at least for 5.4, we are not going on with
> the nils-in-table proposal. Although we really like the idea, the
> compatibility problems seem too big. As this message evidentiates again,
> the language would need a lot of extra stuff (metamethods, API calls,
> etc.), even when the option is off.

Thank you for that!

Introducing integers in Lua 5.3 without major compatibility issues was
an amazing design and engineering feat, but understandably that's not
something that can be pulled off every time. Throughout its history,
Lua was never afraid to make bold compatibility breaks that have
always led to a much-improved language (scoping rules, metamethods
come to mind). I look forward to a future major release where
nils-in-tables are introduced as cleanly as possible without
compatibility compromises, and at the same time I'm happy that 5.4 is
shaping up to be a very smooth upgrade.

-- Hisham