[ANN] Lua 5.4.0 (alpha) now available

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

[ANN] Lua 5.4.0 (alpha) now available

Luiz Henrique de Figueiredo
Lua 5.4.0 (alpha) has been frozen and is now available for testing at
        http://www.lua.org/work/lua-5.4.0-alpha.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 of changes are available at
        http://www.lua.org/work/

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 (alpha) now available

Andrew Gierth
>>>>> "Luiz" == Luiz Henrique de Figueiredo <[hidden email]> writes:

 Luiz> http://www.lua.org/work/lua-5.4.0-alpha.tar.gz

 Luiz> The checksums are
 Luiz> MD5 d49d30b394794b96ffad53513ac647a5  -
 Luiz> SHA1 cf3559dc43cad35463740c6fbedeb1ea501e5e23  -

SHA256 (or better) is usually preferred these days.

 Luiz> This is an alpha version. Some details may change in the final
 Luiz> version.

So, is there any likelihood of changes with regard to the error handling
issues, or do I put up my "this project will never support Lua 5.4"
notice now?

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Patrick Donnelly
In reply to this post by Luiz Henrique de Figueiredo
On Thu, Jun 13, 2019 at 6:36 AM Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.4.0 (alpha) has been frozen and is now available for testing at
>         http://www.lua.org/work/lua-5.4.0-alpha.tar.gz

Great release! A few comments (some of which may already have been
beaten to death in other threads, sorry if I'm rebooting them):

- lua_resetthread is hard to find if you start by looking at
coroutine.close. Can we rename it lua_closethread or rename
coroutine.close to coroutine.reset?

- Maybe it's time to have a coroutine metatable? __index = coroutine,
__close = coroutine.close ?

- I think it's really important that "local <toclose> foo, err =
bar()" be allowed. Otherwise plugging this into code that uses
multireturns for error passing will have a lot of difficulty adopting
<toclose>. (I'm thinking of Nmap's NSE.)

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
> - lua_resetthread is hard to find if you start by looking at
> coroutine.close. Can we rename it lua_closethread or rename
> coroutine.close to coroutine.reset?

A Lua thread can be reused after lua_resetthread.
A coroutine cannot be reused after coroutine.close.
Hence the different names.

Reply | Threaded
Open this post in threaded view
|

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

Viacheslav Usov
In reply to this post by Patrick Donnelly
On Fri, Jun 14, 2019 at 6:43 PM Patrick Donnelly <[hidden email]> wrote:

> - I think it's really important that "local <toclose> foo, err = bar()" be allowed.

This is probably bikeshedding, but:

local (x scoped), (y const), (z const alias) = a, b, c

Modifiers follow a variable in parentheses, which is both invalid in earlier versions and obvious enough to infer what applies to what, even when multiple modifiers are used.

Note that this syntax does not require the modifiers to be true keywords, they can be contextual keywords that have a special meaning only when following an identifier in such a parenthetical declaration, and can be used as identifiers elsewhere (like, for example, the override specifier in C++). So this, for example:

local (scoped scoped), (const const) = a, b

declares a scoped variable 'scoped' and a const variable 'const'.

I would further allow plain and parenthetical declarations to be mixed together freely, and even omit initialisation:

local (x scoped), y

In this case, 'x' and 'y' are nil-initialised. Even in the current 5.4 alpha, a runtime check is required to enforce the mandatory initialisation rule for <toclose> variables, and nils are explicitly allowed, so there is no functional difference.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: More on errors in finalizers (was: [ANN] Lua 5.4.0 (alpha) now available)

David Heiko Kolf-2
In reply to this post by Andrew Gierth
Andrew Gierth wrote:
> So, is there any likelihood of changes with regard to the error
> handling issues, or do I put up my "this project will never support
> Lua 5.4" notice now?

I have now checked how .NET handles errors during garbage collection and
noticed this discussion on Stack Overflow:
<https://stackoverflow.com/questions/2692004/c-sharp-finalizer-throwing-exception>

In summary, .NET 1.1 just ignored exceptions during GC, later .NET
versions kill the entire application regardless of any try-catch blocks.

<https://docs.microsoft.com/en-us/dotnet/api/system.object.finalize?view=netframework-4.8>:
> If Finalize or an override of Finalize throws an exception, and the
> runtime is not hosted by an application that overrides the default
> policy, the runtime terminates the process and no active try/finally
> blocks or finalizers are executed. This behavior ensures process
> integrity if the finalizer cannot free or destroy resources.

I am not sure how that could be translated to Lua, I don't want Lua to
terminate the host application. But whatever the solution, it should
work well with plain Lua and not just a specialized implementation of pcall.

As a further remark, I have been taught that exceptions in finalizers
(in any programming language) should be avoided at all costs, so I hope
my applications never trigger it.

Regarding the associated lua_WarnFunction I am feeling more and more
uneasy, but that is probably a topic for its own thread.

Best regards,

David

Reply | Threaded
Open this post in threaded view
|

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

Egor Skriptunoff-2
In reply to this post by Viacheslav Usov
On Fri, Jun 14, 2019 at 11:22 PM Viacheslav Usov wrote:
This is probably bikeshedding, but:
local (x scoped), (y const), (z const alias) = a, b, c



This is a nice bikeshedding!
From aesthetic point of view, it looks more pleasant than other possible syntax such as <const>, @const and :const
Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
On 20/06/2019 07:39, Egor Skriptunoff wrote:

> On Fri, Jun 14, 2019 at 11:22 PM Viacheslav Usov wrote:
>
>> This is probably bikeshedding, but:
>> local (x scoped), (y const), (z const alias) = a, b, c
>>
>>
>
> This is a nice bikeshedding!
>>From aesthetic point of view, it looks more pleasant than other possible
> syntax such as <const>, @const and :const
>
Definitely!

As far as bikeshedding goes :-) I was one of the proponent of the @const
syntax because interfered less with my "internal parser" (angle brackets
are either too C++ or they may be confused with relops, especially with
long list of attributes).

This new suggestion is both elegant and readable. "()" means "grouping"
anyway in Lua, so no confusion. The "(var_name att_list)" allows both
multiple var declarations in a single local statement and also multiple
attribute /with no comma inbetween/ (which could confuse reader in long
statements with both multiple vars AND multiple attributes.

This might also elegantly allow parametrized attributes (e.g. for
optional type checking)

Contrived example with hard wrapping (and funny attributes):

local (x const helpful alias ),
    (y const alias integer(32) ),
    (z const final float(64) ),
    (errmsg const string(256) whatever )
= mytable, 345, 23.4, myfunc(a,b,c)

Still quite readable!

I think I love it! :-)

I hope this doesn't open the door to some nasty ambiguity (I can't say,
I'm no big grammar expert) so that Lua team may possibly consider its
adoption!

The only problem I see is that it can't be applied so easily to global
variables or table fields, if ever this was a long term goal.

Hooray for Viacheslav! :-)

Cheers!

-- Lorenzo



Reply | Threaded
Open this post in threaded view
|

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

Rodrigo Azevedo
In reply to this post by Egor Skriptunoff-2
Em Qui, 20 de jun de 2019 02:40, Egor Skriptunoff <[hidden email]> escreveu:
On Fri, Jun 14, 2019 at 11:22 PM Viacheslav Usov wrote:
This is probably bikeshedding, but:
local (x scoped), (y const), (z const alias) = a, b, c



This is a nice bikeshedding!
From aesthetic point of view, it looks more pleasant than other possible syntax such as <const>, @const and :const

+1

As a 'per Name' syntax, but 'scoped' is not a good word.


Maybe, it could be extended to a 'per type' 'local'

(local const) x, y, z =...

Where x, y and z are all 'const'.






Reply | Threaded
Open this post in threaded view
|

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

Paul Ducklin
In reply to this post by Lorenzo Donati-3
Add two new keywords. Avoid complex syntactic hacks!



> On 20 Jun 2019, at 10:22, Lorenzo Donati <[hidden email]> wrote:
>
>> On 20/06/2019 07:39, Egor Skriptunoff wrote:
>>> On Fri, Jun 14, 2019 at 11:22 PM Viacheslav Usov wrote:
>>>
>>> This is probably bikeshedding, but:
>>> local (x scoped), (y const), (z const alias) = a, b, c
>>>
>>>
>>
>> This is a nice bikeshedding!
>>> From aesthetic point of view, it looks more pleasant than other possible
>> syntax such as <const>, @const and :const
>>
> Definitely!
>
> As far as bikeshedding goes :-) I was one of the proponent of the @const syntax because interfered less with my "internal parser" (angle brackets are either too C++ or they may be confused with relops, especially with long list of attributes).
>
> This new suggestion is both elegant and readable. "()" means "grouping" anyway in Lua, so no confusion. The "(var_name att_list)" allows both multiple var declarations in a single local statement and also multiple attribute /with no comma inbetween/ (which could confuse reader in long statements with both multiple vars AND multiple attributes.
>
> This might also elegantly allow parametrized attributes (e.g. for optional type checking)
>
> Contrived example with hard wrapping (and funny attributes):
>
> local (x const helpful alias ),
>   (y const alias integer(32) ),
>   (z const final float(64) ),
>   (errmsg const string(256) whatever )
> = mytable, 345, 23.4, myfunc(a,b,c)
>
> Still quite readable!
>
> I think I love it! :-)
>
> I hope this doesn't open the door to some nasty ambiguity (I can't say, I'm no big grammar expert) so that Lua team may possibly consider its adoption!
>
> The only problem I see is that it can't be applied so easily to global variables or table fields, if ever this was a long term goal.
>
> Hooray for Viacheslav! :-)
>
> Cheers!
>
> -- Lorenzo
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Viacheslav Usov
In reply to this post by Lorenzo Donati-3
On Thu, Jun 20, 2019 at 10:22 AM Lorenzo Donati <[hidden email]> wrote:

> The only problem I see is that it can't be applied so easily to global variables

One of the reasons I proposed the 'alias' attribute was a hope it could be used to "declare" globals, but I admit I did not think that fully through.

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
In reply to this post by Paul Ducklin
On 20/06/2019 12:43, Paul Ducklin wrote:
> Add two new keywords. Avoid complex syntactic hacks!
>
>

Adding keywords is more disruptive to old code. Moreover, if more
attributes were needed in the future you will have solved nothing.

Here the attempt is to come up with a syntax which is both readable and
backward compatible AND that allows future extensions without further
syntax change.


>
>> On 20 Jun 2019, at 10:22, Lorenzo Donati <[hidden email]> wrote:
>>
>>> On 20/06/2019 07:39, Egor Skriptunoff wrote:
>>>> On Fri, Jun 14, 2019 at 11:22 PM Viacheslav Usov wrote:
>>>>
>>>> This is probably bikeshedding, but:
>>>> local (x scoped), (y const), (z const alias) = a, b, c
>>>>
>>>>
>>>
>>> This is a nice bikeshedding!
>>>> From aesthetic point of view, it looks more pleasant than other possible
>>> syntax such as <const>, @const and :const
>>>
>> Definitely!
>>
>> As far as bikeshedding goes :-) I was one of the proponent of the @const syntax because interfered less with my "internal parser" (angle brackets are either too C++ or they may be confused with relops, especially with long list of attributes).
>>
>> This new suggestion is both elegant and readable. "()" means "grouping" anyway in Lua, so no confusion. The "(var_name att_list)" allows both multiple var declarations in a single local statement and also multiple attribute /with no comma inbetween/ (which could confuse reader in long statements with both multiple vars AND multiple attributes.
>>
>> This might also elegantly allow parametrized attributes (e.g. for optional type checking)
>>
>> Contrived example with hard wrapping (and funny attributes):
>>
>> local (x const helpful alias ),
>>   (y const alias integer(32) ),
>>   (z const final float(64) ),
>>   (errmsg const string(256) whatever )
>> = mytable, 345, 23.4, myfunc(a,b,c)
>>
>> Still quite readable!
>>
>> I think I love it! :-)
>>
>> I hope this doesn't open the door to some nasty ambiguity (I can't say, I'm no big grammar expert) so that Lua team may possibly consider its adoption!
>>
>> The only problem I see is that it can't be applied so easily to global variables or table fields, if ever this was a long term goal.
>>
>> Hooray for Viacheslav! :-)
>>
>> Cheers!
>>
>> -- Lorenzo
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
In reply to this post by Rodrigo Azevedo
On 20/06/2019 12:36, Rodrigo Azevedo wrote:

> Em Qui, 20 de jun de 2019 02:40, Egor Skriptunoff <
> [hidden email]> escreveu:
>
>> On Fri, Jun 14, 2019 at 11:22 PM Viacheslav Usov wrote:
>>
>>> This is probably bikeshedding, but:
>>> local (x scoped), (y const), (z const alias) = a, b, c
>>>
>>>
>>
>> This is a nice bikeshedding!
>> From aesthetic point of view, it looks more pleasant than other possible
>> syntax such as <const>, @const and :const
>>
>
> +1
>
> As a 'per Name' syntax, but 'scoped' is not a good word.
>
>

Yep, but a little better than "toclose", IMO (and the related metamethod
could be named as "__scope_handler", for example, which is more readable
and explicit than "__close").

Actually it would be nice if someone could come up with a word that coul
express the real concept clearly. For example: "at_scope_end" (or and
"__at_scope_end" as a metamethod. Of course those are UGLY.

Maybe "atend"? It's more explicit than "toclose" since actually
describes that something happens when execution flow reaches the "end"
keyword. "__atend" is not bad as a metamethod.


> Maybe, it could be extended to a 'per type' 'local'
>
> (local const) x, y, z =...
>
> Where x, y and z are all 'const'.
>

Mmmh, here the syntax is getting really messy.


Reply | Threaded
Open this post in threaded view
|

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

Rodrigo Azevedo
Em qui, 20 de jun de 2019 às 11:58, Lorenzo Donati
<[hidden email]> escreveu:

>
> On 20/06/2019 12:36, Rodrigo Azevedo wrote:
> > Em Qui, 20 de jun de 2019 02:40, Egor Skriptunoff <
> > [hidden email]> escreveu:
> >
> >> On Fri, Jun 14, 2019 at 11:22 PM Viacheslav Usov wrote:
> >>
> >>> This is probably bikeshedding, but:
> >>> local (x scoped), (y const), (z const alias) = a, b, c
> >>>
> >>>
> >>
> >> This is a nice bikeshedding!
> >> From aesthetic point of view, it looks more pleasant than other possible
> >> syntax such as <const>, @const and :const
> >>
> >
> > +1
> >
> > As a 'per Name' syntax, but 'scoped' is not a good word.
> >
> >
>
> Yep, but a little better than "toclose", IMO (and the related metamethod
> could be named as "__scope_handler", for example, which is more readable
> and explicit than "__close").
>
> Actually it would be nice if someone could come up with a word that coul
> express the real concept clearly. For example: "at_scope_end" (or and
> "__at_scope_end" as a metamethod. Of course those are UGLY.
>
> Maybe "atend"? It's more explicit than "toclose" since actually
> describes that something happens when execution flow reaches the "end"
> keyword. "__atend" is not bad as a metamethod.
>
>
> > Maybe, it could be extended to a 'per type' 'local'
> >
> > (local const) x, y, z =...
> >
> > Where x, y and z are all 'const'.
> >
>
> Mmmh, here the syntax is getting really messy.

Could be messy,  but useful also.
If each reserved word could be 'annotated' with the syntax
( reserved_word annotation1 annotation2 etc )
such that almost everything after 'reserved_word' can be
simply ignored by standard Lua, with the exception of some 'const' and
'close' related things,  then we could write

(local const) ten = 10

mysqrt = (function integer integer) (a,b)
        (return number) math.sqrt (a*a + b*b)
end

(local my awesome annotation) x,y = 4,5

(local integer) x = 0
(for unroll 4 parallel) i=1,10 do
        x = x+i
end

(do parallel) something() end
--

It is not so ugly. It is readable and Lua has very few keywords
that can be easily parsed by anyone, including a simple
'remove all' for compatibility with previous versions.

 We can even write a simple personalized preprocessor
and also keep the source compatible with standard Lua.




















--
Rodrigo Azevedo Moreira da Silva

Reply | Threaded
Open this post in threaded view
|

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

Hugo Musso Gualandi
In reply to this post by Lorenzo Donati-3
In Python the equivalent metamethod is called __exit__

(There is also a corresponding method called __enter__, which is called at the start of the scope)



>Actually it would be nice if someone could come up with a word that
>coul
>express the real concept clearly. For example: "at_scope_end" (or and
>"__at_scope_end" as a metamethod. Of course those are UGLY.
>
>Maybe "atend"? It's more explicit than "toclose" since actually
>describes that something happens when execution flow reaches the "end"
>keyword. "__atend" is not bad as a metamethod.

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.


On 2019-06-20 4:06 p.m., Hugo Musso Gualandi wrote:

> In Python the equivalent metamethod is called __exit__
>
> (There is also a corresponding method called __enter__, which is called at the start of the scope)
>
>
>
> >Actually it would be nice if someone could come up with a word that
> >coul
> >express the real concept clearly. For example: "at_scope_end" (or and
> >"__at_scope_end" as a metamethod. Of course those are UGLY.
> >
> >Maybe "atend"? It's more explicit than "toclose" since actually
> >describes that something happens when execution flow reaches the "end"
> >keyword. "__atend" is not bad as a metamethod.
>

local <with> foo = bar --> calls bar's __enter metamethod?
end --> calls bar's __exit metamethod?

this also has the benefit of handling nested scopes as well, I guess?

Reply | Threaded
Open this post in threaded view
|

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

Patrick Donnelly
Hi Soni,

On Thu, Jun 20, 2019 at 12:18 PM Soni "They/Them" L. <[hidden email]> wrote:

> On 2019-06-20 4:06 p.m., Hugo Musso Gualandi wrote:
> > In Python the equivalent metamethod is called __exit__
> >
> > (There is also a corresponding method called __enter__, which is called at the start of the scope)
> >
> >
> >
> > >Actually it would be nice if someone could come up with a word that
> > >coul
> > >express the real concept clearly. For example: "at_scope_end" (or and
> > >"__at_scope_end" as a metamethod. Of course those are UGLY.
> > >
> > >Maybe "atend"? It's more explicit than "toclose" since actually
> > >describes that something happens when execution flow reaches the "end"
> > >keyword. "__atend" is not bad as a metamethod.
> >
>
> local <with> foo = bar --> calls bar's __enter metamethod?
> end --> calls bar's __exit metamethod?
>
> this also has the benefit of handling nested scopes as well, I guess?

We don't need Python's cumbersome "with" semantics as Lua has real
variable scoping. See also [1].

Also thinking about [2] more, where I proposed "bind" instead of
"toclose", I'm wondering if Lua should embrace binding the value's
lifetime to the variable (local) by calling __gc instead of __close.
Is there a good use-case for a value whose lifetime persists after
__close? If Lua calls __gc in a deterministic way, it resolves the
same issues and it can mark the value such that it no longer needs the
extra __gc cycle for finalization (IIRC how that works).

[1] http://lua-users.org/lists/lua-l/2018-07/msg00463.html
[2] http://lua-users.org/lists/lua-l/2019-06/msg00405.html

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.


On 2019-06-20 5:15 p.m., Patrick Donnelly wrote:

> Hi Soni,
>
> On Thu, Jun 20, 2019 at 12:18 PM Soni "They/Them" L. <[hidden email]> wrote:
> > On 2019-06-20 4:06 p.m., Hugo Musso Gualandi wrote:
> > > In Python the equivalent metamethod is called __exit__
> > >
> > > (There is also a corresponding method called __enter__, which is called at the start of the scope)
> > >
> > >
> > >
> > > >Actually it would be nice if someone could come up with a word that
> > > >coul
> > > >express the real concept clearly. For example: "at_scope_end" (or and
> > > >"__at_scope_end" as a metamethod. Of course those are UGLY.
> > > >
> > > >Maybe "atend"? It's more explicit than "toclose" since actually
> > > >describes that something happens when execution flow reaches the "end"
> > > >keyword. "__atend" is not bad as a metamethod.
> > >
> >
> > local <with> foo = bar --> calls bar's __enter metamethod?
> > end --> calls bar's __exit metamethod?
> >
> > this also has the benefit of handling nested scopes as well, I guess?
>
> We don't need Python's cumbersome "with" semantics as Lua has real
> variable scoping. See also [1].
>
> Also thinking about [2] more, where I proposed "bind" instead of
> "toclose", I'm wondering if Lua should embrace binding the value's
> lifetime to the variable (local) by calling __gc instead of __close.
> Is there a good use-case for a value whose lifetime persists after
> __close? If Lua calls __gc in a deterministic way, it resolves the
> same issues and it can mark the value such that it no longer needs the
> extra __gc cycle for finalization (IIRC how that works).
>
> [1] http://lua-users.org/lists/lua-l/2018-07/msg00463.html
> [2] http://lua-users.org/lists/lua-l/2019-06/msg00405.html
>

local <toclose> file1 = f
local <toclose> file2 = file1

(consider the case of a nested function call)

python's "cumbersome" "with" semantics would allow you to only close the
file when file1's scope ends, not when the nested function call ends.
this can be quite useful.

Reply | Threaded
Open this post in threaded view
|

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

Coda Highland
In reply to this post by Patrick Donnelly


On Thu, Jun 20, 2019 at 3:16 PM Patrick Donnelly <[hidden email]> wrote:
Hi Soni,

On Thu, Jun 20, 2019 at 12:18 PM Soni "They/Them" L. <[hidden email]> wrote:
> On 2019-06-20 4:06 p.m., Hugo Musso Gualandi wrote:
> > In Python the equivalent metamethod is called __exit__
> >
> > (There is also a corresponding method called __enter__, which is called at the start of the scope)
> >
> >
> >
> > >Actually it would be nice if someone could come up with a word that
> > >coul
> > >express the real concept clearly. For example: "at_scope_end" (or and
> > >"__at_scope_end" as a metamethod. Of course those are UGLY.
> > >
> > >Maybe "atend"? It's more explicit than "toclose" since actually
> > >describes that something happens when execution flow reaches the "end"
> > >keyword. "__atend" is not bad as a metamethod.
> >
>
> local <with> foo = bar --> calls bar's __enter metamethod?
> end --> calls bar's __exit metamethod?
>
> this also has the benefit of handling nested scopes as well, I guess?

We don't need Python's cumbersome "with" semantics as Lua has real
variable scoping. See also [1].

Also thinking about [2] more, where I proposed "bind" instead of
"toclose", I'm wondering if Lua should embrace binding the value's
lifetime to the variable (local) by calling __gc instead of __close.
Is there a good use-case for a value whose lifetime persists after
__close? If Lua calls __gc in a deterministic way, it resolves the
same issues and it can mark the value such that it no longer needs the
extra __gc cycle for finalization (IIRC how that works).

[1] http://lua-users.org/lists/lua-l/2018-07/msg00463.html
[2] http://lua-users.org/lists/lua-l/2019-06/msg00405.html

--
Patrick Donnelly


I disagree with tying this feature to the garbage collector. The current design is recursive; every opening has a corresponding close. Making it part of the garbage collector would mean that no matter how many openings you have, there will only ever be one close.

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

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

Dibyendu Majumdar
In reply to this post by Luiz Henrique de Figueiredo
On Thu, 13 Jun 2019 at 14:36, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>
> Lua 5.4.0 (alpha) has been frozen and is now available for testing at
>         http://www.lua.org/work/lua-5.4.0-alpha.tar.gz
>

Hi,

1) Adding a 'toclose' variable in the 'for' loop is an undesirable
feature in my opinion. Not aware of any language that does that.

2) With regards to the 'toclose' variable declaration, introducing a
'with' statement is the nicest approach.

with <vars> = <initializers> do

end

This idiom is familiar to most programmers who use Python.
BTW @Patrick Donnelly this has nothing to do with Python's reasons for it etc.

3) Finally I feel the 'const' feature can be omitted so that leaves
only one syntactical addition as above, and gets rid of the issue of
annotations for now.  (I am for a generic annotations capability but I
feel it isn't a good fit here - I agree with Daurnimator on this
point).


Regards
Dibyendu

12345