[ANN] Lua 5.4.0 (alpha-rc2) now available

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

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Sean Conner
It was thus said that the Great Kenneth Lorber once stated:
> From: Roberto Ierusalimschy <[hidden email]>
>
> > > Right now, my only complain with the <toclose> is the term "close" that I
> > > found a bit vague and over-loaded (conceptually).
>
> > Suggestions are welcome.
>
> <onescape>
> metamethod __escaped

  One scape?
  Ones cape?

  -spc (Yes, I see it's 'on escape' but it looks weird to me ... )


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Egor Skriptunoff-2
On Sat, Jun 15, 2019 at 9:35 PM Sean Conner wrote:
It was thus said that the Great Kenneth Lorber once stated:
> From: Roberto Ierusalimschy <[hidden email]>
>
> > > Right now, my only complain with the <toclose> is the term "close" that I
> > > found a bit vague and over-loaded (conceptually).
>
> > Suggestions are welcome.
>
> <onescape>
> metamethod __escaped

  One scape?
  Ones cape?

  -spc (Yes, I see it's 'on escape' but it looks weird to me ... )



Let's add some drama to Lua programming :-)
local <jailed> x = setmetatable(obj, {__escaped = ...})
local <perishable> x = setmetatable(obj, {__expired = ...})

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Roberto Ierusalimschy
In reply to this post by Daurnimator
> It's not so much the platform as what future compiler versions may do.
> These divisions by 0 are nasal-demon situations.

Can you be more specific? I always learned that division by 0 in IEEE
floats was something well defined and well behaved. Most compilers
try not to interfere with IEEE semantics.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Coda Highland
On Sat, Jun 15, 2019 at 3:25 PM Roberto Ierusalimschy <[hidden email]> wrote:
> It's not so much the platform as what future compiler versions may do.
> These divisions by 0 are nasal-demon situations.

Can you be more specific? I always learned that division by 0 in IEEE
floats was something well defined and well behaved. Most compilers
try not to interfere with IEEE semantics.

-- Roberto


The well-defined semantics of division by zero are part of Annex F of the C specification, which is an optional thing that compilers are not required to implement. In the absence of Annex F, division by zero has undefined behavior. C++ doesn't have anything like Annex F and division by zero is stated to be undefined (although they mention in a non-normative comment that most implementations allow the behavior to be controlled using library functions).

A division by zero could result in a trap, exception, or signal such as SIGFPE. The convention has been to move away from those behaviors because it's convenient to use 1.0/0 as a way to get infinity, but unless Lua's documentation specifically requires that you don't do that, nothing stops you from passing a compiler flag or calling a library function to change that.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Patrick Donnelly
In reply to this post by Roberto Ierusalimschy
On Wed, Jun 12, 2019 at 5:46 AM Roberto Ierusalimschy
<[hidden email]> wrote:
>
> > Right now, my only complain with the <toclose> is the term "close" that I
> > found a bit vague and over-loaded (conceptually).
>
> Suggestions are welcome.

I've thought about this some and would suggest "bind" or "bound"
instead of "toclose". I think explaining it is easier: the lifetime of
the value is **bound** to the lifetime of the local. (The binding is
bidirectional too since the variable is implicitly const.)

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Aapo Talvensaari
In reply to this post by Roberto Ierusalimschy
On Wed, Jun 12, 2019 at 3:46 PM Roberto Ierusalimschy <[hidden email]> wrote:
> Right now, my only complain with the <toclose> is the term "close" that I
> found a bit vague and over-loaded (conceptually).

Suggestions are welcome.

Name aside, what about something similar to:
http://luajit.org/ext_ffi_api.html#ffi_gc

E.g.

local f = toclose(io.open("myfile"), function(f)
  f:close()
end)
io.close(toclose(f, nil))


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Roberto Ierusalimschy
In reply to this post by Coda Highland
> The well-defined semantics of division by zero are part of Annex F of the C
> specification, which is an optional thing that compilers are not required
> to implement. In the absence of Annex F, division by zero has undefined
> behavior. C++ doesn't have anything like Annex F and division by zero is
> stated to be undefined (although they mention in a non-normative comment
> that most implementations allow the behavior to be controlled using library
> functions).
>
> A division by zero could result in a trap, exception, or signal such as
> SIGFPE. The convention has been to move away from those behaviors because
> it's convenient to use 1.0/0 as a way to get infinity, but unless Lua's
> documentation specifically requires that you don't do that, nothing stops
> you from passing a compiler flag or calling a library function to change
> that.

That part I know. C is not required to implement IEEE arithmetic (as it
is not required to use 2-complement integers). But repeating my original
question, does anyone know of real platforms where this may cause real
problems? Lua always has allowed division by 0 and we have never got any
report about problems there.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Coda Highland


On Mon, Jun 17, 2019 at 8:39 AM Roberto Ierusalimschy <[hidden email]> wrote:
> The well-defined semantics of division by zero are part of Annex F of the C
> specification, which is an optional thing that compilers are not required
> to implement. In the absence of Annex F, division by zero has undefined
> behavior. C++ doesn't have anything like Annex F and division by zero is
> stated to be undefined (although they mention in a non-normative comment
> that most implementations allow the behavior to be controlled using library
> functions).
>
> A division by zero could result in a trap, exception, or signal such as
> SIGFPE. The convention has been to move away from those behaviors because
> it's convenient to use 1.0/0 as a way to get infinity, but unless Lua's
> documentation specifically requires that you don't do that, nothing stops
> you from passing a compiler flag or calling a library function to change
> that.

That part I know. C is not required to implement IEEE arithmetic (as it
is not required to use 2-complement integers). But repeating my original
question, does anyone know of real platforms where this may cause real
problems? Lua always has allowed division by 0 and we have never got any
report about problems there.

-- Roberto


Once upon a time I remember "how do I turn on error handling for division by zero?" being a common question in my programming circles. I haven't seen it recently because the mainstream behavior is kinda assumed by this point.

I think the main reason you wouldn't get reports of problems is because such a report would imply that someone is using such a system unknowingly. Given that it's an opt-in kind of feature on the dominant software platforms, encountering a FPE means either (1) you turned on FPEs, or (2) you're using a niche platform. In either case, the developer is likely to understand what's going on and not blame Lua for it.

On the assumption that Lua doesn't intentionally do divisions by zero in the internals or in the standard library, you can get away with documenting that division by zero is undefined for Lua scripts. If you want to explicitly define the behavior, then you'll need to likewise explicitly handle it in the code.

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

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Paul Ducklin
In reply to this post by Roberto Ierusalimschy
From memory on macOS (building with clang) I have always observed (and have assumed I can take as a given) that a regular division by zero gives me some sort of infinity while an integer division by zero causes an error.

Maybe it’s worth adding this is as a “semantic definition” for Lua arithmetic so that it is unambiguous? That leaves it up to the implementer (perhaps even by means of optional macros that are compiled away by default) to ensure that the semantics are followed.

That would allow builds made for systems like Bochs, Valgrind and so on to handle these cases consistently with real world builds.


On 17 Jun 2019, at 14:39, Roberto Ierusalimschy <[hidden email]> wrote:

>> The well-defined semantics of division by zero are part of Annex F of the C
>> specification, which is an optional thing that compilers are not required
>> to implement. In the absence of Annex F, division by zero has undefined
>> behavior. C++ doesn't have anything like Annex F and division by zero is
>> stated to be undefined (although they mention in a non-normative comment
>> that most implementations allow the behavior to be controlled using library
>> functions).
>>
>> A division by zero could result in a trap, exception, or signal such as
>> SIGFPE. The convention has been to move away from those behaviors because
>> it's convenient to use 1.0/0 as a way to get infinity, but unless Lua's
>> documentation specifically requires that you don't do that, nothing stops
>> you from passing a compiler flag or calling a library function to change
>> that.
>
> That part I know. C is not required to implement IEEE arithmetic (as it
> is not required to use 2-complement integers). But repeating my original
> question, does anyone know of real platforms where this may cause real
> problems? Lua always has allowed division by 0 and we have never got any
> report about problems there.
>
> -- Roberto
>
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Roberto Ierusalimschy
In reply to this post by Coda Highland
> I think the main reason you wouldn't get reports of problems is because
> such a report would imply that someone is using such a system unknowingly.
> Given that it's an opt-in kind of feature on the dominant software
> platforms, encountering a FPE means either (1) you turned on FPEs, or (2)
> you're using a niche platform. In either case, the developer is likely to
> understand what's going on and not blame Lua for it.

According to the C standard, overflows in floating-point arithmetic are
undefined behavior, too. (ISO/IEC 9899:1999 (E) 6.5-5.)

If you are considering "turned on FPEs" as part of the game, would
we have to handle other stuff like floating overflow and underflow
traps, besides division by zero?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Roberto Ierusalimschy
> According to the C standard, overflows in floating-point arithmetic are
> undefined behavior, too. (ISO/IEC 9899:1999 (E) 6.5-5.)
>
> If you are considering "turned on FPEs" as part of the game, would
> we have to handle other stuff like floating overflow and underflow
> traps, besides division by zero?

(Since the beginning, my question is not rhetorical. I really want to
know whether there is a concrete reason to add a special case in the
division by zero. It is very easy to do that, we only have to slightly
change the macro 'luai_numdiv'. But it seems weird to add code to
do what in my view all machines do by themselves without that extra
code. Checking floating overflows is another matter...)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Coda Highland


On Mon, Jun 17, 2019 at 3:36 PM Roberto Ierusalimschy <[hidden email]> wrote:
> According to the C standard, overflows in floating-point arithmetic are
> undefined behavior, too. (ISO/IEC 9899:1999 (E) 6.5-5.)
>
> If you are considering "turned on FPEs" as part of the game, would
> we have to handle other stuff like floating overflow and underflow
> traps, besides division by zero?

(Since the beginning, my question is not rhetorical. I really want to
know whether there is a concrete reason to add a special case in the
division by zero. It is very easy to do that, we only have to slightly
change the macro 'luai_numdiv'. But it seems weird to add code to
do what in my view all machines do by themselves without that extra
code. Checking floating overflows is another matter...)

-- Roberto


I don't believe there is, and that's what I had said before: I think that it's sufficient to document that floating point exceptions are handled according to the underlying C library and that Lua makes no additional promises. If you really want to make stricter promises then of course you have to put forth the effort to enforce those promises, but I don't think there's any noteworthy real-world scenario where this matters.

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

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Hisham
In reply to this post by Aapo Talvensaari
On Mon, 17 Jun 2019 at 05:11, Aapo Talvensaari
<[hidden email]> wrote:

>
> On Wed, Jun 12, 2019 at 3:46 PM Roberto Ierusalimschy <[hidden email]> wrote:
>>
>> > Right now, my only complain with the <toclose> is the term "close" that I
>> > found a bit vague and over-loaded (conceptually).
>>
>> Suggestions are welcome.
>
>
> Name aside, what about something similar to:
> http://luajit.org/ext_ffi_api.html#ffi_gc

The behavior of ffi.gc is analogous to Lua's already-existing __gc metamethod.

> E.g.
>
> local f = toclose(io.open("myfile"), function(f)
>   f:close()
> end)
> io.close(toclose(f, nil))

This is not an option because the to-close behavior in Lua 5.4 is
relative to the variable, not the value.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc2) now available

Egil Hjelmeland
In reply to this post by Luiz Henrique de Figueiredo
Very insignificant minor comment to the manual: When checking the manual
for the modest changes to the print() function, I realized that it does
not mention that the arguments printed are separated by TAB. That goes
back at least to 5.1, which is as far back as my interest goes. I guess
that since that behavior has been there at least since 5.1, is not a
"implementation dependent behavior", and could be mentioned in the
manual in a subsentence.

Den 07.06.2019 01:33, skrev Luiz Henrique de Figueiredo:

> Lua 5.4.0 (alpha-rc2) is now available for testing at
> http://www.lua.org/work/lua-5.4.0-alpha-rc2.tar.gz
>
> The checksums are
> MD5 d49d30b394794b96ffad53513ac647a5  -
> SHA1 cf3559dc43cad35463740c6fbedeb1ea501e5e23  -
>
> This is an alpha 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-rc1 to alpha-rc2 are available at
> http://www.lua.org/work/diffs-lua-5.4.0-alpha-rc1-rc2.html
> http://www.lua.org/work/diffu-lua-5.4.0-alpha-rc1-rc2.html
>
> 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
>

123