[ANN] Lua 5.4.0 (beta) now available

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

[ANN] Lua 5.4.0 (beta) now available

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

The checksums are
        MD5 eb6b27dfd42fb47aec5d1516c3487c68  -
        SHA1 0813c72e04a349cf3623c7d44b7fd0abafe92fd7  -

This is an beta version. Some details may change in the final version.

The main changes in Lua 5.4.0 are listed at
        http://www.lua.org/work/doc/#changes

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

The complete diffs from alpha to beta-rc1 are available at
        http://www.lua.org/work/diffs-lua-5.4.0-alpha-beta-rc1.html
        http://www.lua.org/work/diffu-lua-5.4.0-alpha-beta-rc1.html

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

If your platform is a common Unix-like platform, just do
        make guess
The Makefile will guess your platform using uname and build Lua for it.
We welcome feedback on this, which is new, especially more uname targets
with explicit rules and fixes for existing ones.

We also welcome feedback on the listings output by luac -l -l, because
luac has been rewritten to account for the new VM instructions.

All feedback welcome. Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
Am 02.10.19 um 23:54 schröbte Luiz Henrique de Figueiredo:
> Lua 5.4.0 (beta) is now available for testing at
> http://www.lua.org/work/lua-5.4.0-beta-rc1.tar.gz
>
> All feedback welcome. Thanks.

`debug.setcstacklimit` explicitly returns `false` on error. Shouldn't it
return `fail` instead?

> --lhf

Philipp



Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> Am 02.10.19 um 23:54 schröbte Luiz Henrique de Figueiredo:
> >Lua 5.4.0 (beta) is now available for testing at
> > http://www.lua.org/work/lua-5.4.0-beta-rc1.tar.gz
> >
> >All feedback welcome. Thanks.
>
> `debug.setcstacklimit` explicitly returns `false` on error. Shouldn't it
> return `fail` instead?

Probably.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Phil Leblanc
In reply to this post by Luiz Henrique de Figueiredo
On Wed, Oct 2, 2019 at 9:54 PM Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>
> Lua 5.4.0 (beta) is now available for testing at
>         http://www.lua.org/work/lua-5.4.0-beta-rc1.tar.gz
>
(...)
> All feedback welcome. Thanks.
> --lhf
>
I am surprised with the 'fail' notation thing.  Was I living under a
rock and did I miss some discussion here? :-)

returning (nil, error_message) looks like a well established idiom,
and I understand that Lua 5.4 is going to change that.  I have also
read in section "6  - The Standard Libraries" that  "Currently, fail
is equal to nil, but that may change in future versions."

Also "The recommendation is to test the success of these functions
with (not status), instead of (status == nil)", so obviously 'fail' is
going to be a third false value.

Could you please elaborate on your plans?  Is it to use 'fail' for
error and somehow allow 'nil' in tables?

As I said above,  returning (nil, error_message) is a well established
idiom, used by probably all Lua libraries, C extension modules and
programs. Do you expect library developers to update their code to use
'fail', or keep dual version using 'fail' for new Lua and keep using
nil for old pre-5.4 Lua? Or define in their libraries a global
'fail=nil' which would defeat your (future) purpose?

I am puzzled.

Phil

Reply | Threaded
Open this post in threaded view
|

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

Tomás Guisasola
Em qui, 3 de out de 2019 às 14:19, Phil Leblanc <[hidden email]> escreveu:
> I am surprised with the 'fail' notation thing.  Was I living under a
> rock and did I miss some discussion here? :-)
I feel the same...

> Also "The recommendation is to test the success of these functions
> with (not status), instead of (status == nil)", so obviously 'fail' is
> going to be a third false value.
By using (not status) we would not differ a false return value from a fail.

> Could you please elaborate on your plans?  Is it to use 'fail' for
> error and somehow allow 'nil' in tables?
Good!

> As I said above,  returning (nil, error_message) is a well established
> idiom, used by probably all Lua libraries, C extension modules and
> programs. Do you expect library developers to update their code to use
> 'fail', or keep dual version using 'fail' for new Lua and keep using
> nil for old pre-5.4 Lua? Or define in their libraries a global
> 'fail=nil' which would defeat your (future) purpose?
Be careful not to define 'fail = true' !  Maybe we shoud define a local instead!

> I am puzzled.
Me too.  But, as always, Roberto will explain everything ;-)

Regards,
Tomás

Reply | Threaded
Open this post in threaded view
|

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

Jonathan Goble
On Thu, Oct 3, 2019, 1:38 PM Tomás Guisasola <[hidden email]> wrote:
Em qui, 3 de out de 2019 às 14:19, Phil Leblanc <[hidden email]> escreveu:
> I am surprised with the 'fail' notation thing.  Was I living under a
> rock and did I miss some discussion here? :-)
I feel the same...

> Also "The recommendation is to test the success of these functions
> with (not status), instead of (status == nil)", so obviously 'fail' is
> going to be a third false value.
By using (not status) we would not differ a false return value from a fail.

> Could you please elaborate on your plans?  Is it to use 'fail' for
> error and somehow allow 'nil' in tables?
Good!

> As I said above,  returning (nil, error_message) is a well established
> idiom, used by probably all Lua libraries, C extension modules and
> programs. Do you expect library developers to update their code to use
> 'fail', or keep dual version using 'fail' for new Lua and keep using
> nil for old pre-5.4 Lua? Or define in their libraries a global
> 'fail=nil' which would defeat your (future) purpose?
Be careful not to define 'fail = true' !  Maybe we shoud define a local instead!

> I am puzzled.
Me too.  But, as always, Roberto will explain everything ;-)

Regards,
Tomás

My understanding from a very quick glance at the manual (and without looking at the code) earlier today is that fail is not an actual defined value in itself, but rather a documentation notation indicating an arbitrary value whose only guarantee is that it tests false in a boolean context. Currently the only such values are nil and false itself, and functions that return fail on failure currently return nil, but they are opening the door to change that to a different falsy value (either false itself or a new falsy value) arbitrarily while saying that you can't rely on it to be a specific value, only to satisfy the condition "not value".

As for useful return values, the idiom in Lua has long been that functions which signal failure via return values return a falsy value and an error message on failure and "true" followed by the actual useful return values on success. As far as I could tell, that hasn't changed at all, so the first return value from such functions is merely a boolean indicator of success or failure and the useful data (on success) begins with the second return value. 

Again, this is from a quick glance through the reference manual diffs, and without looking at the code, so it's very possible I missed something major, but it's the impression I got from the reference manual changes. 
Reply | Threaded
Open this post in threaded view
|

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

Tomás Guisasola
Hi Jonathan

Em qui, 3 de out de 2019 às 16:03, Jonathan Goble <[hidden email]> escreveu:
> As for useful return values, the idiom in Lua has long been that functions which signal failure via return values return a falsy value and an error message on failure and "true" followed by the actual useful return values on success. As far as I could tell, that hasn't changed at all, so the first return value from such functions is merely a boolean indicator of success or failure and the useful data (on success) begins with the second return value.
Not exactly.  The function io.open, for instance, does not return a
"true", just the actual file handler on success.  On a failure, it
returns nil followed by an error message.  IIRC, the two functions
that work the way you described are pcall and xpcall, since both are
very general functions.  Note that if that was the protocol (always
return a boolean followed by the actual values), there would be no
reason to adopt a "fail" value, don't you think?

Regards,
Tomás

Reply | Threaded
Open this post in threaded view
|

Lua 5.4.0 (beta) implicit fallthrough warning

Hugo Musso Gualandi
In reply to this post by Luiz Henrique de Figueiredo
On my system, gcc 9.2 prints an "implicit fallthrough" warning for lcode.c on line 1651.

To silence the warning the FALLTHROUGH comment must be moved to AFTER the closing brace, so there is nothing between it and the "case OPR_DIV"
Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Tomás Guisasola
> Not exactly.  The function io.open, for instance, does not return a
> "true", just the actual file handler on success.  On a failure, it
> returns nil followed by an error message.  IIRC, the two functions
> that work the way you described are pcall and xpcall, since both are
> very general functions.

Indeed, several functions return useful values in case of success.
Nevertheless, they overload the first result as a value that signals
success or failure, too. 'io.open' on success does not return true, but
it returns a truly value.

With hindsight, I sometimes regret that when we introduced booleans in
Lua, decades ago, we did not change the standard error return "nil, msg"
to "false, msg". If nil is some kind of "absent value", it is weird that
"msg" comes after something that is not there.

So, the motivation for the change is to move our minds from the
concept that errors return (nil,msg) to the concept that errors return
(falsy,msg). Maybe one day in the distant future we might change
that falsy to false instead of nil.

As a killing argument for the change in style, "if not x then" is
more efficient than "if x == nil then", so everybody should be using
that by now  :-)

There are zero ("zero" as "no chance") of a new falsy value in Lua.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.0 (beta) implicit fallthrough warning

Roberto Ierusalimschy
In reply to this post by Hugo Musso Gualandi
> On my system, gcc 9.2 prints an "implicit fallthrough" warning for lcode.c on line 1651.
>
> To silence the warning the FALLTHROUGH comment must be moved to AFTER the closing brace, so there is nothing between it and the "case OPR_DIV"

Thanks.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

François Perrad
In reply to this post by Luiz Henrique de Figueiredo


Le mer. 2 oct. 2019 à 23:54, Luiz Henrique de Figueiredo <[hidden email]> a écrit :
Lua 5.4.0 (beta) is now available for testing at
        http://www.lua.org/work/lua-5.4.0-beta-rc1.tar.gz

The checksums are
        MD5     eb6b27dfd42fb47aec5d1516c3487c68  -
        SHA1    0813c72e04a349cf3623c7d44b7fd0abafe92fd7  -

This is an beta version. Some details may change in the final version.

The main changes in Lua 5.4.0 are listed at
        http://www.lua.org/work/doc/#changes

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

The complete diffs from alpha to beta-rc1 are available at
        http://www.lua.org/work/diffs-lua-5.4.0-alpha-beta-rc1.html
        http://www.lua.org/work/diffu-lua-5.4.0-alpha-beta-rc1.html

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

If your platform is a common Unix-like platform, just do
        make guess
The Makefile will guess your platform using uname and build Lua for it.
We welcome feedback on this, which is new, especially more uname targets
with explicit rules and fixes for existing ones.

We also welcome feedback on the listings output by luac -l -l, because
luac has been rewritten to account for the new VM instructions.

All feedback welcome. Thanks.

find in attachment some fixes for minor issues (found with a linter).

François
 
--lhf


0001-const.patch (2K) Download Attachment
0002-switch.patch (532 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
> find in attachment some fixes for minor issues (found with a linter).

Thanks for the report.

Reply | Threaded
Open this post in threaded view
|

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

Jorge Visca
In reply to this post by Roberto Ierusalimschy

On 3/10/19 17:57, Roberto Ierusalimschy wrote:

> With hindsight, I sometimes regret that when we introduced booleans in
> Lua, decades ago, we did not change the standard error return "nil, msg"
> to "false, msg". If nil is some kind of "absent value", it is weird that
> "msg" comes after something that is not there.
>
> So, the motivation for the change is to move our minds from the
> concept that errors return (nil,msg) to the concept that errors return
> (falsy,msg). Maybe one day in the distant future we might change
> that falsy to false instead of nil.
>
The classic way still makes lots of sense to me. false is something you
can perfectly expect from a function, just as any other value. There are
a lot of functions where you pass data and ask if some property is true
or false: is_prime(n), button_pressed(b), in_bounding_box(p,b), etc.
Even pcall fits this pattern, because you are asking if the function you
passed can be executed successfully.

The "weird" return is nil, because I interpret it as "could not produce
a value to return". If we look at it with Pascal eyes, it looks like a
broken function call because it could not provide a return.


Jorge


Reply | Threaded
Open this post in threaded view
|

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

Petri Häkkinen
In reply to this post by Roberto Ierusalimschy

> On 3 Oct 2019, at 23.57, Roberto Ierusalimschy <[hidden email]> wrote:
>
> So, the motivation for the change is to move our minds from the
> concept that errors return (nil,msg) to the concept that errors return
> (falsy,msg). Maybe one day in the distant future we might change
> that falsy to false instead of nil.

I’m sorry but I fail to see any improvement here. How does false signal an error any better than nil? This change of a well established idiom will only introduce inconsistency between old and new code I’m afraid.

Petri
Reply | Threaded
Open this post in threaded view
|

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

Egor Skriptunoff-2
On Mon, Oct 7, 2019 at 10:48 PM Petri Häkkinen wrote:

> So, the motivation for the change is to move our minds from the
> concept that errors return (nil,msg) to the concept that errors return
> (falsy,msg). Maybe one day in the distant future we might change
> that falsy to false instead of nil.

I’m sorry but I fail to see any improvement here. How does false signal an error any better than nil?


Probably, Roberto wants to guarantee that an array  {any_standard_function()}  will be a sequence.
Hence such array will become traversable with ipairs.
This might reduce nilophoby in Lua :-)

Reply | Threaded
Open this post in threaded view
|

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

Russell Haley


On Mon, Oct 7, 2019 at 3:12 PM Egor Skriptunoff <[hidden email]> wrote:
On Mon, Oct 7, 2019 at 10:48 PM Petri Häkkinen wrote:

> So, the motivation for the change is to move our minds from the
> concept that errors return (nil,msg) to the concept that errors return
> (falsy,msg). Maybe one day in the distant future we might change
> that falsy to false instead of nil.

I’m sorry but I fail to see any improvement here. How does false signal an error any better than nil?


Probably, Roberto wants to guarantee that an array  {any_standard_function()}  will be a sequence.
Hence such array will become traversable with ipairs.
This might reduce nilophoby in Lua :-)

Okay, that makes some sense to me, but `fail` is not a keyword and I can assign a value to `fail`. Is fail just a concept?

Should I start explicitly returning false instead of just letting values be nil? Returning nil as the first return value IS weird but it's a pattern I have grown fond of.

Russ

Reply | Threaded
Open this post in threaded view
|

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

William Ahern
On Mon, Oct 07, 2019 at 10:24:14PM -0700, Russell Haley wrote:

> On Mon, Oct 7, 2019 at 3:12 PM Egor Skriptunoff <[hidden email]>
> wrote:
>
> > On Mon, Oct 7, 2019 at 10:48 PM Petri Häkkinen wrote:
> >
> >>
> >> > So, the motivation for the change is to move our minds from the
> >> > concept that errors return (nil,msg) to the concept that errors return
> >> > (falsy,msg). Maybe one day in the distant future we might change
> >> > that falsy to false instead of nil.
> >>
> >> I’m sorry but I fail to see any improvement here. How does false signal
> >> an error any better than nil?
> >>
> >>
> > Probably, Roberto wants to guarantee that an array
> > *{any_standard_function()}*  will be a sequence.
> > Hence such array will become traversable with ipairs.
> > This might reduce nilophoby in Lua :-)
> >
> > Okay, that makes some sense to me, but `fail` is not a keyword and I can
> assign a value to `fail`. Is fail just a concept?
>
> Should I start explicitly returning false instead of just letting values be
> nil? Returning nil as the first return value IS weird but it's a pattern I
> have grown fond of.
>

Is it wierd or just reflective of a difficult problem domain? As an
undergraduate (late 1990s) I took a programming class in the statistics
department. I forget my professor's name but he worked for one of the
government agencies in Washington, D.C. tracking labor and other economic
data, including processing and analysis of questionaires. After class for a
couple of evenings he *attempted* to explain to me a research paper he had
written some years prior regarding how to encode missing, null, empty, 0,
incomplete, erroneous, etc answers. It was all completely over my head; I
didn't even understand the existing, well-accepted types let alone his
extensions of them that he was so excited about.

What I do know is that the number of such types he was trying to explain
were more numerous than any set I've since been able to find in the computer
science literature. Which explains his excitement. IIRC, he was a scholar in
the data science field, so presumably his ideas went straight to the heart
of some important theories in applied math and statistics.

My impression is that false and nil are woefully inadequate to express the
various nuances demanded of such types. OTOH, exactly what you want or
should express can be very difficult to identify. So whether Lua only has 1,
2, or 4 such types[1], I don't think there's any getting away from the
sentiment that the set of available types is either incomplete or
superfluous, depending on the context.

[1] My vague recollection is that he was arguing for either 3 or 4 unique
xtypes, or 1 more than whatever the established, minimal set.

Reply | Threaded
Open this post in threaded view
|

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

Philippe Verdy


Le mar. 8 oct. 2019 à 21:06, William Ahern <[hidden email]> a écrit :
On Mon, Oct 07, 2019 at 10:24:14PM -0700, Russell Haley wrote:
> On Mon, Oct 7, 2019 at 3:12 PM Egor Skriptunoff <[hidden email]>
> wrote:
>
> > On Mon, Oct 7, 2019 at 10:48 PM Petri Häkkinen wrote:
> >
> >>
> >> > So, the motivation for the change is to move our minds from the
> >> > concept that errors return (nil,msg) to the concept that errors return
> >> > (falsy,msg). Maybe one day in the distant future we might change
> >> > that falsy to false instead of nil.
All this looks like an attempt (or goal) to provide proper exception handling in Lua.

If you think about Lua 6, one goal will be to support real exceptions and exception handlers in the language (i.e. try..catch, and possibly finally using the new "toclose" semantics supported in the VM). In which case we would no longer need to return any fail status explicitly, we would just throw an exception (passing an exception object allocated and initialized in the "try" part, so that no exception would occur to build the error object to throw and that will be caught in a matching catch handler).

The difficulty is to reinforce the typing system for exception types, something that Lua still cannot do cleanly without custom tests (if/elseif or switch) on "typeof" error objects, in a process that can be quite slow and is still not as much optimized as it is in C++. Lua could be inspired by C# (which uses a string typing system) or Javascript (which uses a lax dynamic typing system but that can be hinted to considitonally validate the typing system).

Note that if C# has a very strong typing system, this has a cost on the compiler (because ensuring strict type safety is very complex, it's an NP-problem whose resolution rapidly explodes exponentially, and can result in very short programs to hang the compiler with arbitrarily large CPU time/cycles or memory/stack resources needed with lot of contexts needed in stack for backtracking). And C# still cannot assert that a program will not break the engine at runtime or will not cause the program to never halt: systems need then to implement resource monitors and watchdogs to enforce some safe limits, but Lua has still not been designed to behave correctly if resources are exhausted (the lifetime of its allocated resources is not very well managed and its garbage collector and scheduler has many unpredictable behavior when we are near the limits; this forces many systems to drop support for some APIs that cannot be safely rollbacked.)

But may be the simpler model of "structured exception handlers" (as in C and in the windows API) may be implementable without that complexity and without NP-completess for the dynamic typesystem. In which case exception handlers in Lua would not be based on error object types (including inheritance tests) but constant object values (the problem being that it will be difficult to avoid the case of "uncaught exceptions" as applciations would have to document all exceptions that must be caught as part or their own API, and exception thrown by internal APIs used in their implementation. In Java at least there's a worling model that does not require NP-complexity and provides good compile times. In Javascript, Google designed quite an efficient system for dynamic type inference at runtime, needing low levels of storage, but the dynamic type system of Javascript is as simple as it is in Lua, where dynamic type inference is possible to cover at runtime the dynamic type to stronger type system using caches which then become JIT compilable to native code which can be thrown on the dustbiun when no longer needed, and when a derived type is built dynamically from an object, and is not or cannot be compiled, the dynamic evaluation of structured error handlers can still be interpreted instead of being compiled to native code with a strong type system.





Reply | Threaded
Open this post in threaded view
|

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

Hugo Musso Gualandi

> If you think about Lua 6, one goal will be to support real exceptions
> and exception handlers in the language (i.e. try..catch, and possibly
> finally using the new "toclose" semantics supported in the VM).

As far as I know, the reason why Lua uses pcall instead of try-catch
blocks has more to do with the Lua-C API than it has to do with types.
The pcall function can be easily exposed to C, but there is no obvious
way to do the same with try-catch blocks.

I believe this is also the main motivation for to-be-closed variables
instead of try-finally blocks.