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

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

Patrick Donnelly
On Thu, Jun 20, 2019 at 1:24 PM Coda Highland <[hidden email]> wrote:

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

Current design doesn't have an __open so I don't really see how a
recursive open/close could be effectively used when only __close is
called.

If you're thinking about recursive locks, that's still very possible
with proxy "locker" objects that exist only for the duration of the
scope.

--
Patrick Donnelly

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 Dibyendu Majumdar
On Thu, Jun 20, 2019 at 1:51 PM Dibyendu Majumdar
<[hidden email]> wrote:
> 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.

Quoting myself from the prior thread:

"I want to point out the reasons why Python requires a control
structure but Lua would not: Python's locals are function-scoped.
Declaring a local in Python means it doesn't go out of scope until the
function returns. For this reason, Python requires an explicit control
structure to define the lifetime of the variable. Lua does not have
this limitation."

They absolutely needed another control structure to implement their
flavor of RAII.

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

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

Dibyendu Majumdar
On Thu, 20 Jun 2019 at 21:59, Patrick Donnelly <[hidden email]> wrote:
>
=> > 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.
>
> Quoting myself from the prior thread:
>
> "I want to point out the reasons why Python requires a control
> structure but Lua would not: Python's locals are function-scoped.
> Declaring a local in Python means it doesn't go out of scope until the
> function returns. For this reason, Python requires an explicit control
> structure to define the lifetime of the variable. Lua does not have
> this limitation."
>
> They absolutely needed another control structure to implement their
> flavor of RAII.
>

And I repeat that the suggestion to use this syntax doesn't have
anything to do with why Python had to have it. It is a nice idiom used
in many languages. C# calls it 'using'. In Java we have try with
resources. But all are the same construct.

Regards

Reply | Threaded
Open this post in threaded view
|

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

Patrick Donnelly
On Thu, Jun 20, 2019 at 2:07 PM Dibyendu Majumdar
<[hidden email]> wrote:

>
> On Thu, 20 Jun 2019 at 21:59, Patrick Donnelly <[hidden email]> wrote:
> >
> => > 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.
> >
> > Quoting myself from the prior thread:
> >
> > "I want to point out the reasons why Python requires a control
> > structure but Lua would not: Python's locals are function-scoped.
> > Declaring a local in Python means it doesn't go out of scope until the
> > function returns. For this reason, Python requires an explicit control
> > structure to define the lifetime of the variable. Lua does not have
> > this limitation."
> >
> > They absolutely needed another control structure to implement their
> > flavor of RAII.
> >
>
> And I repeat that the suggestion to use this syntax doesn't have
> anything to do with why Python had to have it. It is a nice idiom used
> in many languages. C# calls it 'using'. In Java we have try with
> resources. But all are the same construct.

Fine, but I haven't seen a good argument for __enter so a "with"
construct looks unnecessary, distracting, and unnecessary indentation.

--
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 6:13 p.m., Patrick Donnelly wrote:

> On Thu, Jun 20, 2019 at 2:07 PM Dibyendu Majumdar
> <[hidden email]> wrote:
> >
> > On Thu, 20 Jun 2019 at 21:59, Patrick Donnelly <[hidden email]> wrote:
> > >
> > => > 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.
> > >
> > > Quoting myself from the prior thread:
> > >
> > > "I want to point out the reasons why Python requires a control
> > > structure but Lua would not: Python's locals are function-scoped.
> > > Declaring a local in Python means it doesn't go out of scope until the
> > > function returns. For this reason, Python requires an explicit control
> > > structure to define the lifetime of the variable. Lua does not have
> > > this limitation."
> > >
> > > They absolutely needed another control structure to implement their
> > > flavor of RAII.
> > >
> >
> > And I repeat that the suggestion to use this syntax doesn't have
> > anything to do with why Python had to have it. It is a nice idiom used
> > in many languages. C# calls it 'using'. In Java we have try with
> > resources. But all are the same construct.
>
> Fine, but I haven't seen a good argument for __enter so a "with"
> construct looks unnecessary, distracting, and unnecessary indentation.
>

a "with" construct is unnecessary even with __enter, and I'd argue it'd
be beneficial to have __enter without "with": assignment to a toclose
variable (or uh, a with variable) would cause __enter, and when it goes
out of scope, an __close.

e.g. let's say you want a function that can be passed a file directly or
as part of a larger processing chain:

local function do_something_with_file(f)
     local <with> f = f -- f:__enter()
     f:write("hello!\n")
     -- f:__close()
end

do_something_with_file(io.open("foo", "w")) -- okay, file gets closed

local <with> f = io.open("bar", "w") -- f:__enter()
do_something_with_file(f) -- doesn't close file
f:write("goodbye!\n")
-- f:__close() -- file gets closed

Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
Am 21.06.19 um 00:16 schröbte Soni "They/Them" L.:
>
> local function do_something_with_file(f)
>      local <with> f = f -- f:__enter()
>      f:write("hello!\n")
>      -- f:__close()
> end

You shouldn't dispose objects you didn't allocate in any Lua version
because the code that did allocate the object might still need it after
you have returned. And that makes <toclose>/<with> nesting superfluous.

>
> do_something_with_file(io.open("foo", "w")) -- okay, file gets closed
>
> local <with> f = io.open("bar", "w") -- f:__enter()
> do_something_with_file(f) -- doesn't close file
> f:write("goodbye!\n")
> -- f:__close() -- file gets closed

I was thinking about this:

local f = io.open("bar", "w")
do_something_with_file(f) -- closes file
f:write("goodbye!\n") -- error


Philipp



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 8:28 p.m., Philipp Janda wrote:

> Am 21.06.19 um 00:16 schröbte Soni "They/Them" L.:
>>
>> local function do_something_with_file(f)
>>      local <with> f = f -- f:__enter()
>>      f:write("hello!\n")
>>      -- f:__close()
>> end
>
> You shouldn't dispose objects you didn't allocate in any Lua version
> because the code that did allocate the object might still need it
> after you have returned. And that makes <toclose>/<with> nesting
> superfluous.
>
>>
>> do_something_with_file(io.open("foo", "w")) -- okay, file gets closed
>>
>> local <with> f = io.open("bar", "w") -- f:__enter()
>> do_something_with_file(f) -- doesn't close file
>> f:write("goodbye!\n")
>> -- f:__close() -- file gets closed
>
> I was thinking about this:
>
> local f = io.open("bar", "w")
> do_something_with_file(f) -- closes file
> f:write("goodbye!\n") -- error
>
>
> Philipp
>
>
>

my point is <toclose> could be an option to support nested contexts. in
addition to plain old :close() that only does unnested contexts. it
would be useful because you'd have two ways to use the same function. it
improves code reuse and thus improves readability and maintainability!

in other words: benefits all around!

Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
Am 21.06.19 um 01:33 schröbte Soni "They/Them" L.:

>
>
> On 2019-06-20 8:28 p.m., Philipp Janda wrote:
>> Am 21.06.19 um 00:16 schröbte Soni "They/Them" L.:
>>>
>>> local function do_something_with_file(f)
>>>      local <with> f = f -- f:__enter()
>>>      f:write("hello!\n")
>>>      -- f:__close()
>>> end
>>
>> You shouldn't dispose objects you didn't allocate in any Lua version
>> because the code that did allocate the object might still need it
>> after you have returned. And that makes <toclose>/<with> nesting
>> superfluous.
>>
>>>
>>> do_something_with_file(io.open("foo", "w")) -- okay, file gets closed
>>>
>>> local <with> f = io.open("bar", "w") -- f:__enter()
>>> do_something_with_file(f) -- doesn't close file
>>> f:write("goodbye!\n")
>>> -- f:__close() -- file gets closed
>>
>> I was thinking about this:
>>
>> local f = io.open("bar", "w")
>> do_something_with_file(f) -- closes file
>> f:write("goodbye!\n") -- error
>>
>>
>
> my point is <toclose> could be an option to support nested contexts. in
> addition to plain old :close() that only does unnested contexts. it
> would be useful because you'd have two ways to use the same function. it
> improves code reuse and thus improves readability and maintainability!

Quoted above are _three_ ways to use the same function. With
`do_something_with_file()` potentially closing its argument only two of
those ways work.

Philipp



Reply | Threaded
Open this post in threaded view
|

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

Francisco Olarte
In reply to this post by Soni "They/Them" L.
On Thu, Jun 20, 2019 at 9:18 PM Soni "They/Them" L. <[hidden email]> wrote:
>
>
>
> On 2019-06-20 4:06 p.m., Hugo Musso Gualandi wrote:
> 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?

I think it's not need and has several problems. 1st, bar can be an
expression, and in my normal use cases it will be, normally tings like
file.open("whatever") or similar.

Also, __enter__ functionality can be easily made by things like
self-returning method, and it makes the code more explicit and easier
to read, i.e. things like "local <toclose> p = ref_counter:ref() (
where in my use case, ref_counter:ref incrementes self:ref_count,
ref_counter:unref decrements it and calls self:no_refs() if it goes to
zero, and __close calls unref )

Also, Lua has nested scopes IIRC, that's what do-end is for, it's even
documented as useful to control variable scope.

Francisco Olarte.


>

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Dibyendu Majumdar
>>>>> "Dibyendu" == Dibyendu Majumdar <[hidden email]> writes:

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

You do realize that this is one of the primary reasons for 'toclose' to
exist at all? The fact that breaking or erroring out of a loop doesn't
give the iterator any chance to clean up is a significant problem (for
example, if iterating over io.lines, the file is not closed until it is
GC'd, which may not happen until much later).

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.


On 2019-06-21 5:34 p.m., Andrew Gierth wrote:

> >>>>> "Dibyendu" == Dibyendu Majumdar <[hidden email]> writes:
>
>   Dibyendu> 1) Adding a 'toclose' variable in the 'for' loop is an
>   Dibyendu> undesirable feature in my opinion. Not aware of any language
>   Dibyendu> that does that.
>
> You do realize that this is one of the primary reasons for 'toclose' to
> exist at all? The fact that breaking or erroring out of a loop doesn't
> give the iterator any chance to clean up is a significant problem (for
> example, if iterating over io.lines, the file is not closed until it is
> GC'd, which may not happen until much later).
>

I'm convinced <toclose> should support nested contexts (read: have an
__enter).

I have, many times, used file:lines() (which is more like
file:read_iter() because you can give it args) in a loop that I would
break out of, and then I'd use the file some more.

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
>>>>> "Soni" == Soni \"They/Them\" L <[hidden email]> writes:

 >> You do realize that this is one of the primary reasons for 'toclose'
 >> to exist at all? The fact that breaking or erroring out of a loop
 >> doesn't give the iterator any chance to clean up is a significant
 >> problem (for example, if iterating over io.lines, the file is not
 >> closed until it is GC'd, which may not happen until much later).

 Soni> I'm convinced <toclose> should support nested contexts (read:
 Soni> have an __enter).

 Soni> I have, many times, used file:lines() (which is more like
 Soni> file:read_iter() because you can give it args) in a loop that I
 Soni> would break out of, and then I'd use the file some more.

Looping on file:lines doesn't close the file at the end of the loop, so
it doesn't close it on break/error either. Only io.lines does that, and
only when not reading from io.input.

--
Andrew.

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 Andrew Gierth
On Fri, 21 Jun 2019 at 21:35, Andrew Gierth <[hidden email]> wrote:

>
> >>>>> "Dibyendu" == Dibyendu Majumdar <[hidden email]> writes:
>
>  Dibyendu> 1) Adding a 'toclose' variable in the 'for' loop is an
>  Dibyendu> undesirable feature in my opinion. Not aware of any language
>  Dibyendu> that does that.
>
> You do realize that this is one of the primary reasons for 'toclose' to
> exist at all? The fact that breaking or erroring out of a loop doesn't
> give the iterator any chance to clean up is a significant problem (for
> example, if iterating over io.lines, the file is not closed until it is
> GC'd, which may not happen until much later).
>

Not sure I understand ... no language I know has this, and yet many
have autoclosing of resources, so clearly it is not the reason for
toclose.

You would simply write:

with <var> = <initializer> do
   for ... do
   end
end

This is what you would do with any other language that supports this construct.

I haven't tried to articulate why this is bad, but here are two points:

1) In my opinion the acquiring of a resource and its auto closure
should be a visible thing.
2) The for loop construct seems a complete random thing. Why not then
do the same in if construct? Or repeat construct?

Regards

Reply | Threaded
Open this post in threaded view
|

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

Patrick Donnelly
On Fri, Jun 21, 2019 at 2:48 PM Dibyendu Majumdar
<[hidden email]> wrote:

>
> On Fri, 21 Jun 2019 at 21:35, Andrew Gierth <[hidden email]> wrote:
> >
> > >>>>> "Dibyendu" == Dibyendu Majumdar <[hidden email]> writes:
> >
> >  Dibyendu> 1) Adding a 'toclose' variable in the 'for' loop is an
> >  Dibyendu> undesirable feature in my opinion. Not aware of any language
> >  Dibyendu> that does that.
> >
> > You do realize that this is one of the primary reasons for 'toclose' to
> > exist at all? The fact that breaking or erroring out of a loop doesn't
> > give the iterator any chance to clean up is a significant problem (for
> > example, if iterating over io.lines, the file is not closed until it is
> > GC'd, which may not happen until much later).
> >
>
> Not sure I understand ... no language I know has this, and yet many
> have autoclosing of resources, so clearly it is not the reason for
> toclose.

For io.lines, Lua automatically closes the file after the last
(successful) line. Unfortunately, there's no integration with the
generic for loop in Lua 5.4. It would be nice if the internal state
variable could be closed when the loop breaks. I guess the Lua authors
have good reasons for not making that change beyond the trivial reason
that the state value in existing code may not be closeable.

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

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

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

 Patrick> For io.lines, Lua automatically closes the file after the last
 Patrick> (successful) line. Unfortunately, there's no integration with
 Patrick> the generic for loop in Lua 5.4.

Huh?

In 5.4, io.lines explicitly _does_ integrate with the generic for loop
to ensure the file is closed (if it was opened and isn't just using
io.input). What makes you think there is not?

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
In reply to this post by Luiz Henrique de Figueiredo
Op Do. 13 Jun. 2019 om 15:36 het Luiz Henrique de Figueiredo
<[hidden email]> geskryf:

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

Why does the syntax not allow e.g. the following?

local <const> x,y = 1,2

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 Andrew Gierth


On Sat, Jun 22, 2019, 2:09 PM Andrew Gierth <[hidden email]> wrote:
>>>>> "Patrick" == Patrick Donnelly <[hidden email]> writes:

 Patrick> For io.lines, Lua automatically closes the file after the last
 Patrick> (successful) line. Unfortunately, there's no integration with
 Patrick> the generic for loop in Lua 5.4.

Huh?

In 5.4, io.lines explicitly _does_ integrate with the generic for loop
to ensure the file is closed (if it was opened and isn't just using
io.input). What makes you think there is not?


Sorry, I meant that there is no integration with generic for loop and the toclose variables, i.e. that breaking out of the for loop will cause the state value to be closed.
Reply | Threaded
Open this post in threaded view
|

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

Francisco Olarte
In reply to this post by Soni "They/Them" L.
Sony:

On Fri, Jun 21, 2019 at 10:42 PM Soni "They/Them" L. <[hidden email]> wrote:
...
> I'm convinced <toclose> should support nested contexts (read: have an
> __enter).

Do you realize you can do "local <toclose> x = ctx.__enter()" ( and
have enter return either self or a helper object )

I think the behaviour is enough, mechanism, you cannot do the
equivalent of <toclose>, but enter is trivial and in fact there are
things like Java which are dessigned to work this way ( try with
resources, which is very similar to <toclose> ).

> I have, many times, used file:lines() (which is more like
> file:read_iter() because you can give it args) in a loop that I would
> break out of, and then I'd use the file some more.

Then do it, it is simple. do, local toclose = file.open, for loop with
may break , some things wihich happen after it, end. No need for enter
anywhere.

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Patrick Donnelly
>>>>> "Patrick" == Patrick Donnelly <[hidden email]> writes:

 >> In 5.4, io.lines explicitly _does_ integrate with the generic for
 >> loop to ensure the file is closed (if it was opened and isn't just
 >> using io.input). What makes you think there is not?

 Patrick> Sorry, I meant that there is no integration with generic for
 Patrick> loop and the toclose variables, i.e. that breaking out of the
 Patrick> for loop will cause the state value to be closed.

But this integration does exist. Why do you think it does not?

The generic for loop in 5.4 takes 4 values, not 3, and the 4th one is
treated as being assigned to a toclose variable. That is to say,

  for foo in a,b,c,d do ... done

will invoke d's __close metamethod when the loop is exited by any means.

io.lines("file") now returns 4 values: readline_func, nil, nil, file
where the readline_func is a closure that returns the next line from the
file, and "file" is the filehandle that was opened, which will be closed
via its __close metamethod.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

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

 Andrew>   for foo in a,b,c,d do ... done

... end, dammit, too much shell lately

--
Andrew.

12345