[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 Sat, Jun 22, 2019 at 2:33 PM Andrew Gierth
<[hidden email]> wrote:

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

Oh, I missed that in the change notes. Sorry for the noise and thanks
for pointing that out!

--
Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
Op So. 23 Jun. 2019 om 02:19 het Patrick Donnelly
<[hidden email]> geskryf:
>
> On Sat, Jun 22, 2019 at 2:33 PM Andrew Gierth
> <[hidden email]> wrote:
> > 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.
>
> Oh, I missed that in the change notes.

You missed it because it is not there. Only the numerical for loop
gets attention.

-- Dirk

Reply | Threaded
Open this post in threaded view
|

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

Jim-2
In reply to this post by Egor Skriptunoff-2
20.06.2019, 07:40, "Egor Skriptunoff" <[hidden email]>:
>> local (x scoped), (y const), (z const alias) = a, b, c

> From aesthetic point of view, it looks more pleasant than other
> possible syntax such as <const>, @const and :const.

To whom does this look more pleasant ?
To LISP programmers ? :D


Reply | Threaded
Open this post in threaded view
|

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

Jim-2
20.06.2019, 07:40, "Egor Skriptunoff" <[hidden email]>:
>>  local (x scoped), (y const), (z const alias) = a, b, c

>  From aesthetic point of view, it looks more pleasant than other
>  possible syntax such as <const>, @const and :const.

why not
local [x scoped], [y const], ...
?

what about an annotation syntax that looks like a comment as in - say -
--@==...==@ attribute arg1 arg2 arg3 ... @==...==@
akin to the
--[==...==[ ... ]==...==]
comments ?

or is there a good reason to use - say - "$==...==$" to close those
(as seen in "]==...==]") ?


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 Andrew Gierth
>>Sorry, I meant that there is no integration
>>with generic for loop and the toclose variables

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

Because it isn’t documented well.

It should be explained more clearly in the manual and should *definitely be listed* amongst the significant changes from 5.3.5 to 5.4.0.

(The minor change in integer for loops is listed as a major change but the major change in generic for loops isn’t listed at all.)

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

This is one of only two places in the whole Lua codebase, and is the only library function, where __close is used (in both cases the code just sets __close = __gc).

Yet the manual fails to mention it at all.

Everyone who was around and concentrating on this list when __close was discussed probably knows all this stuff, but how is anyone else supposed to find out?

I grepped through the code, but I shouldn’t have had to.


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 Jim-2
On Sun, Jun 23, 2019 at 1:50 PM Jim <[hidden email]> wrote:
why not
local [x scoped], [y const], ...

I chose () because this is the "least special" kind of brackets.

I would not mind square brackets, simply because this would entail fewer keystrokes for me, but users of other keyboard layouts might disagree.

Any other characters might be used there equally well, but it is probably reasonable to use something that traditionally implies grouping, and it is not clear to me why multi-char sequences would be advantageous here.

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

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

Jim-2
23.06.2019, 14:54, "Viacheslav Usov" <[hidden email]>:
> I chose () because this is the "least special" kind of brackets.
>
> I would not mind square brackets, simply because this would
> entail fewer keystrokes for me, but users of other keyboard
> layouts might disagree.

admittedly square brackets do not look more pleasant. :-/

> Any other characters might be used there equally well,
> but it is probably reasonable to use something that traditionally
> implies grouping, and it is not clear to me why multi-char
> sequences would be advantageous here.

using multichar sequences that look like comments to older Lua
versions and hence would be ignored by those is no bad idea,
right ?

but then this might boil down to something more in line with
Lua's multiline comments:

--[==...==[@ attr arg1 arg2 arg3 ... @]==...==]

which admittedly does not look too pleasant aswell ... :-/


Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Dirk Laurie-2
> > > 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.
> >
> > Oh, I missed that in the change notes.
>
> You missed it because it is not there. Only the numerical for loop
> gets attention.

It is the second item in the list of changes, right after the
generational GC: "to-be-closed variables".

The list never breaks down the details of each particular change.
For instance, in the list of changes of 5.3 we did not include
"floor division", "math.tointeger", and several other consequences
of the change "integers".

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Sean Conner
In reply to this post by Paul Ducklin
It was thus said that the Great Paul Ducklin once stated:

>
> >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.
>
> This is one of only two places in the whole Lua codebase, and is the only
> library function, where __close is used (in both cases the code just sets
> __close = __gc).

  Now that I think about it, why have __close at all?  Why not have locals
marked as <toclose> just call __gc upon leaving scope?  It is to avoid
possibly code breakage with for loops?

  -spc


Reply | Threaded
Open this post in threaded view
|

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

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

 >> This is one of only two places in the whole Lua codebase, and is the
 >> only library function, where __close is used (in both cases the code
 >> just sets __close = __gc).

 Sean>   Now that I think about it, why have __close at all? Why not
 Sean> have locals marked as <toclose> just call __gc upon leaving
 Sean> scope?

1) you might not want __close and __gc to do the same thing, and if you
   do want it, it's trivial to assign the same function to both

2) it would allow any object with __gc but not __close to be assigned to
   a toclose variable, and that breaks a sandbox's control over error
   handling

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Sean Conner
It was thus said that the Great Andrew Gierth once stated:

> >>>>> "Sean" == Sean Conner <[hidden email]> writes:
>
>  >> This is one of only two places in the whole Lua codebase, and is the
>  >> only library function, where __close is used (in both cases the code
>  >> just sets __close = __gc).
>
>  Sean>   Now that I think about it, why have __close at all? Why not
>  Sean> have locals marked as <toclose> just call __gc upon leaving
>  Sean> scope?
>
> 1) you might not want __close and __gc to do the same thing, and if you
>    do want it, it's trivial to assign the same function to both
>
> 2) it would allow any object with __gc but not __close to be assigned to
>    a toclose variable, and that breaks a sandbox's control over error
>    handling

  How could it break a sandbox?  I mean, I can do:

        f = io.open(somevalidfile)
        f:__gc()

(that only works because the file's metatable has __index set to the
metatalbe, and it has the __gc method visible in it)

  -spc (Puzzled by the "break the sandbox" answers ... )

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 Roberto Ierusalimschy
Op So. 23 Jun. 2019 om 21:42 het Roberto Ierusalimschy
<[hidden email]> geskryf:

> > > > 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.
> > >
> > > Oh, I missed that in the change notes.
> >
> > You missed it because it is not there. Only the numerical for loop
> > gets attention.
>
> It is the second item in the list of changes, right after the
> generational GC: "to-be-closed variables".
>
> The list never breaks down the details of each particular change.
> For instance, in the list of changes of 5.3 we did not include
> "floor division", "math.tointeger", and several other consequences
> of the change "integers".

For the sake those who even now can't find it: don't look in the
"Incompatibilities with the previous version" section of the manual,
but in the file

lua-5.4.0-alpha/doc/readme.html

-- DIrk

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 Sean Conner
Sean:

On Mon, Jun 24, 2019 at 1:06 AM Sean Conner <[hidden email]> wrote:

>   Now that I think about it, why have __close at all?  Why not have locals
> marked as <toclose> just call __gc upon leaving scope?  It is to avoid
> possibly code breakage with for loops?

I, personally, assume no one is ever touching my data structures again
after __gc, and leave them in an invalid state ( yes, I know you can
resurrect them, but any competent programmer can crash a lib ). With
__close I will not assume that, I will leave them in a safe state, and
also assume __close can be called several times easily and make it
idempotent. In a lot of cases they will all be the same, but sometimes
they will not.

Francisco Olarte.

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 Luiz Henrique de Figueiredo
On Thu, Jun 13, 2019 at 4:36 PM Luiz Henrique de Figueiredo wrote:
Lua 5.4.0 (alpha) has been frozen and is now available for testing

All feedback welcome.



1)
Lua 5.3 manual says:
The numerical for-loop repeats a block of code while a control variable
RUNS through an arithmetic progression.

Lua 5.4 manual says:
The numerical for-loop repeats a block of code while a control variable
GOES through an arithmetic progression.

The difference is: "runs" -> "goes".
Why so pessimistic about for-loop speed in Lua 5.4?  :-) 


2)
I don't understand from Lua 5.4 manual whether the "limit" in numeric for-loop is inclusive or exclusive.
Probably that's because of my bad English.
The meaning of the phrase "until that value passes the limit" is vague to me.
Should perfect tense "has passed" be used instead of "passes"?
BTW, Lua 5.3 manual was absolutely clear due to the "equivalent code".

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 Dibyendu Majumdar
On Thu, 20 Jun 2019 at 21:51, 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
>

I realize now that because of the multiple return values from
io.open(), above is not possible, because a 'with' statement would
require that all vars declared are to-be-closed.
When I first saw the introduction of the *toclose annotation, I had
not understood why the annotation was necessary - as I hadn't
understood the ambiguity in syntax without some form of annotation
marker. So it seems we are stuck with some form of annotated local
declaration.

It is interesting how past syntactical choices limit options for
future evolution of the language.

In some ways an ugly syntax for 'toclose' declarations is not a bad
thing, as they draw attention of the reader to the fact. Also explicit
declarations are important for the same reason, and that is why I
think performing automatic close() in a generic for loop is not a good
idea as the reader of the code can't tell what is potentially
happening behind the scenes.

However the ugly syntax for a constant declaration is the side effect
of this; and that is a heavy price to pay. Given that the constant
feature seems to have been added because it was 'free' - perhaps, it
shouldn't be added to the language.

Anyway I am eager to see what comes out of all this. As a feature the
*toclose feature is an important one I think, more important than any
other feature in 5.4 I think. I can't wait to port this to Ravi once
it is finalised.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
Op Do. 27 Jun. 2019 om 13:08 het Dibyendu Majumdar
<[hidden email]> geskryf:

> In some ways an ugly syntax for 'toclose' declarations is not a bad
> thing, as they draw attention of the reader to the fact. Also explicit
> declarations are important for the same reason, and that is why I
> think performing automatic close() in a generic for loop is not a good
> idea as the reader of the code can't tell what is potentially
> happening behind the scenes.

I've been a Lua user for almost ten years, and I've succeeded in
understanding and sometimes using every language addition in that
time. Not so with <toclose>.

My perceptions about it are:

1. It solves a problem encountered by a very small fraction of Lua users.
2. Although it looks like a property of a variable, i.e. a name, it is
a property of the associated value.
3. All variables declared <toclose> must have a metatable with a
__close metamethod, otherwise nothing different happens anyway.
4. Therefore they must be either tables or full userdata.
5. The 5.4 alpha syntax for it is the least ugly among various
possibilities, but still ugly.
6. It runs counter to Lua's design goals of being minimal, neat and compact.

In other words, <toclose> is feature bloat.

> However the ugly syntax for a constant declaration is the side effect
> of this; and that is a heavy price to pay. Given that the constant
> feature seems to have been added because it was 'free' - perhaps, it
> shouldn't be added to the language.

Agreed.

-- Dirk

Reply | Threaded
Open this post in threaded view
|

Yet another proposal for <toclose> (was Re: [ANN] Lua 5.4.0 (alpha) now available)

Sean Conner
It was thus said that the Great Dirk Laurie once stated:

>
> I've been a Lua user for almost ten years, and I've succeeded in
> understanding and sometimes using every language addition in that
> time. Not so with <toclose>.
>
> My perceptions about it are:
>
> 1. It solves a problem encountered by a very small fraction of Lua users.
> 2. Although it looks like a property of a variable, i.e. a name, it is
> a property of the associated value.
> 3. All variables declared <toclose> must have a metatable with a
> __close metamethod, otherwise nothing different happens anyway.
> 4. Therefore they must be either tables or full userdata.
> 5. The 5.4 alpha syntax for it is the least ugly among various
> possibilities, but still ugly.
> 6. It runs counter to Lua's design goals of being minimal, neat and compact.
>
> In other words, <toclose> is feature bloat.

  Reading this, I just had an idea.  It introduces just one new keyword,
removes annotations entirely, and (I think?) introduces just a *bit* of
cognitive overload.

        do
          -- --------------------------------------------------------------
          -- 'scope' is like 'local' in that the variable is local to the
          -- current scope, but unlike 'local', the variable is closed at
          -- the end.  When we leave the current scope, each variable
          -- declared as a 'scope' is checked for a __close metamethod, and
          -- if it exists, it is called; otherwise, nothing happens.
          -- --------------------------------------------------------------
         
          scope f,err = io.open("foobar")
          local x,y,z -- regular locals
         
          -- -----------------------------------------
          -- all variables of type 'scope' are closed
          -- -----------------------------------------
        end

  The current behavior with for (the four parameter that is "closed") can be
kept.

> > However the ugly syntax for a constant declaration is the side effect
> > of this; and that is a heavy price to pay. Given that the constant
> > feature seems to have been added because it was 'free' - perhaps, it
> > shouldn't be added to the language.
>
> Agreed.

  Unless we can get global constants (or constants in a table) then yes, I
agree, the <const> attribute doesn't seem to be all that useful.

  Agreed.

  -spc


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 Dirk Laurie-2
>>>>> "Dirk" == Dirk Laurie <[hidden email]> writes:

 Dirk> I've been a Lua user for almost ten years, and I've succeeded in
 Dirk> understanding and sometimes using every language addition in that
 Dirk> time. Not so with <toclose>.

 Dirk> My perceptions about it are:

 Dirk> 1. It solves a problem encountered by a very small fraction of
 Dirk> Lua users.

Maybe so, but it's a problem that lacks other reasonable solutions.

 Dirk> 2. Although it looks like a property of a variable, i.e. a name,
 Dirk> it is a property of the associated value.

No. This is flat wrong. It is explicitly a property of the variable, and
it is linked to the scope of the variable.

 Dirk> 3. All variables declared <toclose> must have a metatable with a
 Dirk> __close metamethod, otherwise nothing different happens anyway.

Variables don't have metatables, values do. Values assigned to toclose
variables do need to have this metamethod, yes.

 Dirk> 4. Therefore they must be either tables or full userdata.

Correct. So?

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Yet another proposal for <toclose> (was Re: [ANN] Lua 5.4.0 (alpha) now available)

Sergey Kovalev
In reply to this post by Sean Conner
Why we need extra functionality if it could be done with existing one?

>         do
>           -- --------------------------------------------------------------
>           -- 'scope' is like 'local' in that the variable is local to the
>           -- current scope, but unlike 'local', the variable is closed at
>           -- the end.  When we leave the current scope, each variable
>           -- declared as a 'scope' is checked for a __close metamethod, and
>           -- if it exists, it is called; otherwise, nothing happens.
>           -- --------------------------------------------------------------
>
>           scope f,err = io.open("foobar")
>           local x,y,z -- regular locals
>
>           -- -----------------------------------------
>           -- all variables of type 'scope' are closed
>           -- -----------------------------------------
>         end

function scope(body)
    local list,res={}
    local function auto(close,msg)
        return function(t)
            if type(t)~='table' then error("need table: { expression }",2) end
            if t[1] then table.insert(list,{ arg=t[1], fn=close or io.close })
            else
                if msg=='weak' then return table.unpack(t,2) end
                error(msg or t[2] or "no resource",2)
            end
            return table.unpack(t)
        end
    end
    local ok,err=pcall(function() res={body(auto)} end)
    for i=#list,1,-1 do list[i].fn(list[i].arg) end
    if not ok then
        if type(err)~='string' then error(err,2)
        else error("scope error\nlua: "..err,2) end
    end
    return table.unpack(res)
end

scope(function(auto)
    local f=auto(io.close){ io.open "foobar" } -- will be closed
    local g,err=auto(io.close,"weak"){ io.open "foobar2" }
    local x,y,z -- regular locals
end)

Reply | Threaded
Open this post in threaded view
|

Re: Yet another proposal for <toclose> (was Re: [ANN] Lua 5.4.0 (alpha) now available)

Roberto Ierusalimschy
> Why we need extra functionality if it could be done with existing one?
>
> [...]
>     local f=auto(io.close){ io.open "foobar" } -- will be closed

It won't, if the table creation raises a memory error.

-- Roberto

12345