[ANN] Lua 5.4.0 (work1) now available

classic Classic list List threaded Threaded
164 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

[ANN] Lua 5.4.0 (work1) now available

Luiz Henrique de Figueiredo
Lua 5.4.0 (work1) is now available for testing at
        http://www.lua.org/work/lua-5.4.0-work1.tar.gz

The checksums are
        MD5     0ff232b8658884155a43cf72212edbd9  -
        SHA1    a8193b14ed3869917d1102cb0418cf9dfb0d9baf  -

This is a work version. All details may change in the final version.

An updated reference manual is included and also available at
        http://www.lua.org/work/doc

The complete diffs from Lua 5.3 are too extensive to show.

A test suite is available at
        http://www.lua.org/work/lua-5.4.0-work1-tests.tar.gz

All feedback welcome. Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

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

Charles Heywood
Yay! Figures, I just mentioned on IRC that I don't think a work was gonna come out soon, and here you are.

On Tue, Mar 13, 2018 at 10:44 AM Luiz Henrique de Figueiredo <[hidden email]> wrote:
Lua 5.4.0 (work1) is now available for testing at
        http://www.lua.org/work/lua-5.4.0-work1.tar.gz

The checksums are
        MD5     0ff232b8658884155a43cf72212edbd9  -
        SHA1    a8193b14ed3869917d1102cb0418cf9dfb0d9baf  -

This is a work version. All details may change in the final version.

An updated reference manual is included and also available at
        http://www.lua.org/work/doc

The complete diffs from Lua 5.3 are too extensive to show.

A test suite is available at
        http://www.lua.org/work/lua-5.4.0-work1-tests.tar.gz

All feedback welcome. Thanks.
--lhf

--
--
Ryan | Charles <[hidden email]>
Software Developer / System Administrator
Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
A test suite is not yet available. Sorry for the noise.

Reply | Threaded
Open this post in threaded view
|

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

Xavier Wang
  • Congratulations!!!

btw, I notice that there is a new keyword, "undef", not mentions in manual, is that just a undocumented feature or the doc just not the latest?

--
regards,
Xavier Wang.
Reply | Threaded
Open this post in threaded view
|

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

Pierre Chapuis
In reply to this post by Luiz Henrique de Figueiredo
I like the following change:

> The coersion of strings to numbers in arithmetic and bitwise operations has been removed from the core language.

(I think there is a typo here by the way, should be "coercion".)

I have not played with it yet but I hope it will be easy enough to disable the new coercion method that uses metatables.

What is the reasoning behind the full userdata change?

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Luiz Henrique de Figueiredo
>>>>> "Luiz" == Luiz Henrique de Figueiredo <[hidden email]> writes:

 Luiz> All feedback welcome. Thanks.

I think the removal of __ipairs is a serious mistake.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
> I think the removal of __ipairs is a serious mistake.

The __ipairs was deprecated in 5.3 and now removed in 5.4.
See http://www.lua.org/manual/5.3/manual.html#8.2 :

- The ipairs iterator now respects metamethods and its __ipairs
metamethod has been deprecated.

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.


On 2018-03-13 03:13 PM, Luiz Henrique de Figueiredo wrote:
>> I think the removal of __ipairs is a serious mistake.
> The __ipairs was deprecated in 5.3 and now removed in 5.4.
> See http://www.lua.org/manual/5.3/manual.html#8.2 :
>
> - The ipairs iterator now respects metamethods and its __ipairs
> metamethod has been deprecated.
>

When do we get __next?

--
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: [ANN] Lua 5.4.0 (work1) now available

Andrew Gierth
In reply to this post by Luiz Henrique de Figueiredo
>>>>> "Luiz" == Luiz Henrique de Figueiredo <[hidden email]> writes:

 >> I think the removal of __ipairs is a serious mistake.

 Luiz> The __ipairs was deprecated in 5.3 and now removed in 5.4.

Yes, I know. This is the serious mistake to which I referred.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Luiz Henrique de Figueiredo
>>>>> "Luiz" == Luiz Henrique de Figueiredo <[hidden email]> writes:

 Luiz> All feedback welcome. Thanks.

in lvm.c:

#if !defined(LUA_USE_JUMPTABLE)
#define LUA_USE_JUMPTABLE defined(__GNUC__)
#endif

[...]

#if LUA_USE_JUMPTABLE

The above results in undefined behavior. Instead use:

#if !defined(LUA_USE_JUMPTABLE)
#if defined(__GNUC__)
#define LUA_USE_JUMPTABLE 1
#else
#define LUA_USE_JUMPTABLE 0
#endif
#endif

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> in lvm.c:
>
> #if !defined(LUA_USE_JUMPTABLE)
> #define LUA_USE_JUMPTABLE defined(__GNUC__)
> #endif
>
> [...]
>
> #if LUA_USE_JUMPTABLE
>
> The above results in undefined behavior. Instead use:
>
> [...]

Sure. Thanks,

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Pierre Chapuis
> What is the reasoning behind the full userdata change?

Flexibility? (Most userdata do not use their user value, so we can save
a few bytes in that case; some userdata need more than one associated
value, and it can be expensive to allocate a new table for each userdata.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Xavier Wang
> btw, I notice that there is a new keyword, "undef", not mentions in manual,
> is that just a undocumented feature or the doc just not the latest?

I am grad you asked :-)

Lua 5.4 has an experimental change that is off by default (to keep
compatibility). We plan to keep this off in Lua 5.4 final.
You can turn it on by compiling this version with the option
-DLUA_NILINTABLE. As the name hints, this option allows nils in tables:

>  t = {nil, nil, nil}
> #t
3
> for k,v in pairs(t) do print(k, v) end
1 nil
2 nil
3 nil
> t[#t + 1] = nil
> for k,v in pairs(t) do print(k, v) end
1 nil
2 nil
3 nil
4 nil


Once you have nils in tables, t[i]=nil does not remove elements from
a table anymore. For that, you need to write t[i]=undef.

No, this is not like JavaScript! 'undef' is NOT a value.

t[i]=undef is a special syntax form that means "remove the key 'i'
from table 't'". You can only use 'undef' in three specific forms:

  t[i] = undef     -- remove a key from a table
  t[i] == undef    -- test whether a table has a key
  t[i] ~= undef    -- test whether a table has a key

Any other use of 'undef' gives a syntax error.

You still can create tables with holes, but you must get out of your
way to do it.

The nice thing about this syntax is that it is compatible with
previous versions of Lua (as long as you do not use 'undef' for
other stuff). In Lua 5.0/1/2/3, if you write 't[i] = undef', you remove
the element from the table. Even if we never change Lua to this
new mode, even if you never use Lua 5.4, we think this syntax is
a nice way to document whether an assignment is being done to remove
an element from a table.

(A search for the pattern '][ =~]*nil' finds most of the places
in your code where you could/should use undef instead of nil.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.


On 2018-03-13 04:43 PM, Roberto Ierusalimschy wrote:

>> btw, I notice that there is a new keyword, "undef", not mentions in manual,
>> is that just a undocumented feature or the doc just not the latest?
> I am grad you asked :-)
>
> Lua 5.4 has an experimental change that is off by default (to keep
> compatibility). We plan to keep this off in Lua 5.4 final.
> You can turn it on by compiling this version with the option
> -DLUA_NILINTABLE. As the name hints, this option allows nils in tables:
>
>>   t = {nil, nil, nil}
>> #t
> 3
>> for k,v in pairs(t) do print(k, v) end
> 1 nil
> 2 nil
> 3 nil
>> t[#t + 1] = nil
>> for k,v in pairs(t) do print(k, v) end
> 1 nil
> 2 nil
> 3 nil
> 4 nil
>
>
> Once you have nils in tables, t[i]=nil does not remove elements from
> a table anymore. For that, you need to write t[i]=undef.
>
> No, this is not like JavaScript! 'undef' is NOT a value.
>
> t[i]=undef is a special syntax form that means "remove the key 'i'
> from table 't'". You can only use 'undef' in three specific forms:
>
>    t[i] = undef     -- remove a key from a table
>    t[i] == undef    -- test whether a table has a key
>    t[i] ~= undef    -- test whether a table has a key
>
> Any other use of 'undef' gives a syntax error.
>
> You still can create tables with holes, but you must get out of your
> way to do it.
>
> The nice thing about this syntax is that it is compatible with
> previous versions of Lua (as long as you do not use 'undef' for
> other stuff). In Lua 5.0/1/2/3, if you write 't[i] = undef', you remove
> the element from the table. Even if we never change Lua to this
> new mode, even if you never use Lua 5.4, we think this syntax is
> a nice way to document whether an assignment is being done to remove
> an element from a table.
>
> (A search for the pattern '][ =~]*nil' finds most of the places
> in your code where you could/should use undef instead of nil.)
>
> -- Roberto
>

What about:

a = 1
local a = 2
a = undef
assert(a == 1)?

--
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: [ANN] Lua 5.4.0 (work1) now available

Andrew Starks-2
In reply to this post by Roberto Ierusalimschy

On Tue, Mar 13, 2018 at 14:44 Roberto Ierusalimschy <[hidden email]> wrote:
> btw, I notice that there is a new keyword, "undef", not mentions in manual,
> is that just a undocumented feature or the doc just not the latest?

I am grad you asked :-)

Lua 5.4 has an experimental change that is off by default (to keep
compatibility). We plan to keep this off in Lua 5.4 final.
You can turn it on by compiling this version with the option
-DLUA_NILINTABLE. As the name hints, this option allows nils in tables:

>  t = {nil, nil, nil}
> #t
3
> for k,v in pairs(t) do print(k, v) end
1       nil
2       nil
3       nil
> t[#t + 1] = nil
> for k,v in pairs(t) do print(k, v) end
1       nil
2       nil
3       nil
4       nil


Once you have nils in tables, t[i]=nil does not remove elements from
a table anymore. For that, you need to write t[i]=undef.

No, this is not like JavaScript! 'undef' is NOT a value.

t[i]=undef is a special syntax form that means "remove the key 'i'
from table 't'". You can only use 'undef' in three specific forms:

  t[i] = undef     -- remove a key from a table
  t[i] == undef    -- test whether a table has a key
  t[i] ~= undef    -- test whether a table has a key

Any other use of 'undef' gives a syntax error.

You still can create tables with holes, but you must get out of your
way to do it.

The nice thing about this syntax is that it is compatible with
previous versions of Lua (as long as you do not use 'undef' for
other stuff). In Lua 5.0/1/2/3, if you write 't[i] = undef', you remove
the element from the table. Even if we never change Lua to this
new mode, even if you never use Lua 5.4, we think this syntax is
a nice way to document whether an assignment is being done to remove
an element from a table.

(A search for the pattern '][ =~]*nil' finds most of the places
in your code where you could/should use undef instead of nil.)

-- Roberto

My reaction was: What would you call this new language?

After reading your explanation, I’m very curious about the implications of this in the real world. 

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> After reading your explanation, I’m very curious about the implications of
> this in the real world.

Probably none. As I said in the second line of my explanation, we plan
to keep this off in Lua 5.4 final.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Soni "They/Them" L.
> What about:
>
> a = 1
> local a = 2
> a = undef
> assert(a == 1)?

A main motivation for the implementation was to allow people to
check the behavior by themselves. Run and see.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

答复: [ANN] Lua 5.4.0 (work1) now available

actboy168@gmail.com
In reply to this post by Roberto Ierusalimschy

Great, I like it. I think I will open it.

 

 

发件人: [hidden email]
发送时间: 2018314 3:44
收件人: [hidden email]
主题: Re: [ANN] Lua 5.4.0 (work1) now available

 

> btw, I notice that there is a new keyword, "undef", not mentions in manual,
> is that just a undocumented feature or the doc just not the latest?

I am grad you asked :-)

Lua 5.4 has an experimental change that is off by default (to keep
compatibility). We plan to keep this off in Lua 5.4 final.
You can turn it on by compiling this version with the option
-DLUA_NILINTABLE. As the name hints, this option allows nils in tables:

>  t = {nil, nil, nil}
> #t
3
> for k,v in pairs(t) do print(k, v) end
1       nil
2       nil
3       nil
> t[#t + 1] = nil
> for k,v in pairs(t) do print(k, v) end
1       nil
2       nil
3       nil
4       nil


Once you have nils in tables, t[i]=nil does not remove elements from
a table anymore. For that, you need to write t[i]=undef.

No, this is not like JavaScript! 'undef' is NOT a value.

t[i]=undef is a special syntax form that means "remove the key 'i'
from table 't'". You can only use 'undef' in three specific forms:

  t[i] = undef     -- remove a key from a table
  t[i] == undef    -- test whether a table has a key
  t[i] ~= undef    -- test whether a table has a key

Any other use of 'undef' gives a syntax error.

You still can create tables with holes, but you must get out of your
way to do it.

The nice thing about this syntax is that it is compatible with
previous versions of Lua (as long as you do not use 'undef' for
other stuff). In Lua 5.0/1/2/3, if you write 't[i] = undef', you remove
the element from the table. Even if we never change Lua to this
new mode, even if you never use Lua 5.4, we think this syntax is
a nice way to document whether an assignment is being done to remove
an element from a table.

(A search for the pattern '][ =~]*nil' finds most of the places
in your code where you could/should use undef instead of nil.)

-- Roberto

 

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.
In reply to this post by Roberto Ierusalimschy


On 2018-03-13 05:13 PM, Roberto Ierusalimschy wrote:

>> What about:
>>
>> a = 1
>> local a = 2
>> a = undef
>> assert(a == 1)?
> A main motivation for the implementation was to allow people to
> check the behavior by themselves. Run and see.
>
> -- Roberto
>

I mean it's probably a syntax error but I mean can we get non-lexical
variable scoping?

--
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: [ANN] Lua 5.4.0 (work1) now available

Rodrigo Azevedo
In reply to this post by Roberto Ierusalimschy
Warning: I'm just rambling here!

2018-03-13 16:43 GMT-03:00 Roberto Ierusalimschy <[hidden email]>:
> for k,v in pairs(t) do print(k, v) end
1       nil
2       nil
3       nil
4       nil



I think we're going to need a considerable amount of time to understand these "nils" everywhere. But, could the (new) undef syntax

 
  t[i] = undef     -- remove a key from a table 
  t[i] == undef    -- test whether a table has a key
  t[i] ~= undef    -- test whether a table has a key

Any other use of 'undef' gives a syntax error.


be tied to the removal of the key/values, if possible (not referenced by something)? maybe, to put the key/value in a high priority (newest always) generation (from the new generational gc), such that we could have a more deterministic memory management. Then, the (new) syntax could be extended to non-tables

a = function(x) return x end
a = undef

as a hint for the gc.

--
Rodrigo Azevedo Moreira da Silva
1234 ... 9