[ANN] Lua 5.2.0 (beta-rc2) now available

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

[ANN] Lua 5.2.0 (beta-rc2) now available

Luiz Henrique de Figueiredo
Lua 5.2.0 (beta-rc2) is now available at
        http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz

MD5 9ea65fecf46eaedc72824ed599e5877a  -
SHA1 b0f44b05f6fa36c200fb565c5b2160be5b63e385  -

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

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

The complete diffs from rc1 are available at
        http://www.lua.org/work/diffs-lua-5.2.0-beta-rc1-beta-rc2.txt

A test suite is available at
        http://www.lua.org/tests/5.2/

This release candidate will be the beta version if no glitches are found
in the next 10 days or so. We thank everyone for their feedback till now.

All feedback welcome. Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Peter Cawley
n Tue, Jun 21, 2011 at 11:21 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> Lua 5.2.0 (beta-rc2) is now available at
>        http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz
>
> MD5     9ea65fecf46eaedc72824ed599e5877a  -
> SHA1    b0f44b05f6fa36c200fb565c5b2160be5b63e385  -
>
> This is a beta version. Some details may change in the final version.
>
> The main changes since Lua 5.1 are listed in
>        http://www.lua.org/work/doc/#changes
>
> The complete diffs from rc1 are available at
>        http://www.lua.org/work/diffs-lua-5.2.0-beta-rc1-beta-rc2.txt
>
> A test suite is available at
>        http://www.lua.org/tests/5.2/
>
> This release candidate will be the beta version if no glitches are found
> in the next 10 days or so. We thank everyone for their feedback till now.
>
> All feedback welcome. Thanks.
> --lhf

http://www.lua.org/work/doc/#changes still lists "internal (immutable)
version of ctypes" and lists lctype.c under "Building Lua on other
systems", though it looks like this has been removed since rc1. Also
as a very minor formatting point, the documentation in manual.html for
lua_arith and lua_compare has no whitespace between the colons and the
option descriptions (whereas functions like lua_gc, lua_load,
lua_pcall do all have whitespace).

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

liam mail


On 21 June 2011 23:51, Peter Cawley <[hidden email]> wrote:
n Tue, Jun 21, 2011 at 11:21 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.2.0 (beta-rc2) is now available at
>        http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz
>
> MD5     9ea65fecf46eaedc72824ed599e5877a  -
> SHA1    b0f44b05f6fa36c200fb565c5b2160be5b63e385  -
>
> This is a beta version. Some details may change in the final version.
>
> The main changes since Lua 5.1 are listed in
>        http://www.lua.org/work/doc/#changes
>
> The complete diffs from rc1 are available at
>        http://www.lua.org/work/diffs-lua-5.2.0-beta-rc1-beta-rc2.txt
>
> A test suite is available at
>        http://www.lua.org/tests/5.2/
>
> This release candidate will be the beta version if no glitches are found
> in the next 10 days or so. We thank everyone for their feedback till now.
>
> All feedback welcome. Thanks.
> --lhf

http://www.lua.org/work/doc/#changes still lists "internal (immutable)
version of ctypes" and lists lctype.c under "Building Lua on other
systems", though it looks like this has been removed since rc1. Also
as a very minor formatting point, the documentation in manual.html for
lua_arith and lua_compare has no whitespace between the colons and the
option descriptions (whereas functions like lua_gc, lua_load,
lua_pcall do all have whitespace).


Mac Osx 10.6 x86_64 ran with "./lua -e'_U=true' all.lua"

test done on 21/06/2011, at 23:58:17
Lua 5.2
final OK !!!
cleaning all!!!!
......    ---- total memory: 44K, max memory: 30M ----



total time: 6.62

.>>> closing state <<<


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

dcharno
In reply to this post by Luiz Henrique de Figueiredo
On 06/21/2011 06:21 PM, Luiz Henrique de Figueiredo wrote:

> Lua 5.2.0 (beta-rc2) is now available at
> http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz
>
> MD5 9ea65fecf46eaedc72824ed599e5877a  -
> SHA1 b0f44b05f6fa36c200fb565c5b2160be5b63e385  -
>
> This is a beta version. Some details may change in the final version.
>
> The main changes since Lua 5.1 are listed in
> http://www.lua.org/work/doc/#changes
>
> The complete diffs from rc1 are available at
> http://www.lua.org/work/diffs-lua-5.2.0-beta-rc1-beta-rc2.txt
>
> A test suite is available at
> http://www.lua.org/tests/5.2/
>
> This release candidate will be the beta version if no glitches are found
> in the next 10 days or so. We thank everyone for their feedback till now.
>
> All feedback welcome. Thanks.
> --lhf

The reference manual says labels are visible in the block where they are
defined.  So, why does the following fail in rc2?

        while false do
                break
                goto label
        ::label::
        end

        while false do
                break
                goto label
        ::label::
        end

         $ ./src/lua: t.lua:12: label 'label' already defined on line 6

Aren't ::label:: defined in different blocks?





Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Josh Simmons
On Wed, Jun 22, 2011 at 1:03 PM, dcharno <[hidden email]> wrote:

> On 06/21/2011 06:21 PM, Luiz Henrique de Figueiredo wrote:
>>
>> Lua 5.2.0 (beta-rc2) is now available at
>>        http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz
>>
>> MD5     9ea65fecf46eaedc72824ed599e5877a  -
>> SHA1    b0f44b05f6fa36c200fb565c5b2160be5b63e385  -
>>
>> This is a beta version. Some details may change in the final version.
>>
>> The main changes since Lua 5.1 are listed in
>>        http://www.lua.org/work/doc/#changes
>>
>> The complete diffs from rc1 are available at
>>        http://www.lua.org/work/diffs-lua-5.2.0-beta-rc1-beta-rc2.txt
>>
>> A test suite is available at
>>        http://www.lua.org/tests/5.2/
>>
>> This release candidate will be the beta version if no glitches are found
>> in the next 10 days or so. We thank everyone for their feedback till now.
>>
>> All feedback welcome. Thanks.
>> --lhf
>
> The reference manual says labels are visible in the block where they are
> defined.  So, why does the following fail in rc2?
>
>        while false do
>                break
>                goto label
>        ::label::
>        end
>
>        while false do
>                break
>                goto label
>        ::label::
>        end
>
>        $ ./src/lua: t.lua:12: label 'label' already defined on line 6
>
> Aren't ::label:: defined in different blocks?
>

"A label is visible in the entire block where it is defined (including
nested blocks, but not nested functions). A function cannot have more
than one label with a given name." Emphasis on the second sentence.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

dcharno
On 06/21/2011 11:15 PM, Josh Simmons wrote:

> On Wed, Jun 22, 2011 at 1:03 PM, dcharno<[hidden email]>  wrote:
>> On 06/21/2011 06:21 PM, Luiz Henrique de Figueiredo wrote:
>>>
>>> Lua 5.2.0 (beta-rc2) is now available at
>>>         http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz
>>>
>>> MD5     9ea65fecf46eaedc72824ed599e5877a  -
>>> SHA1    b0f44b05f6fa36c200fb565c5b2160be5b63e385  -
>>>
>>> This is a beta version. Some details may change in the final version.
>>>
>>> The main changes since Lua 5.1 are listed in
>>>         http://www.lua.org/work/doc/#changes
>>>
>>> The complete diffs from rc1 are available at
>>>         http://www.lua.org/work/diffs-lua-5.2.0-beta-rc1-beta-rc2.txt
>>>
>>> A test suite is available at
>>>         http://www.lua.org/tests/5.2/
>>>
>>> This release candidate will be the beta version if no glitches are found
>>> in the next 10 days or so. We thank everyone for their feedback till now.
>>>
>>> All feedback welcome. Thanks.
>>> --lhf
>>
>> The reference manual says labels are visible in the block where they are
>> defined.  So, why does the following fail in rc2?
>>
>>         while false do
>>                 break
>>                 goto label
>>         ::label::
>>         end
>>
>>         while false do
>>                 break
>>                 goto label
>>         ::label::
>>         end
>>
>>         $ ./src/lua: t.lua:12: label 'label' already defined on line 6
>>
>> Aren't ::label:: defined in different blocks?
>>
>
> "A label is visible in the entire block where it is defined (including
> nested blocks, but not nested functions). A function cannot have more
> than one label with a given name." Emphasis on the second sentence.

This working in rc1.  So much for progress.



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Lorenzo Donati-2
In reply to this post by Luiz Henrique de Figueiredo
On 22/06/2011 0.21, Luiz Henrique de Figueiredo wrote:
> Lua 5.2.0 (beta-rc2) is now available at
> http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz
>

[snip]

I see that a constraint has been introduced so that a label cannot be
repeated inside the same function.

I've already argued on the other thread (5.2 beta-rc1) that I'd prefer a
limit "per-block". There I motivated my preference with an use case for
error management.

Now another use case comes to my mind, which will make "continue-fans"
less happy with goto. Please consider:


------------
local s = "apple banana kiwi pear apricot plum mango \*
papaya blackberry coconut strawberry"

local banned_letter = "p"

print( [[---- no "]] .. banned_letter .. [[" fruits ----]] )
for word in s:gmatch '%w+' do
    if word:sub( 1, 1 ) == banned_letter then
       goto continue
    end
    print( word )
::continue::
end

banned_letter = "a"

print( [[---- no "]] .. banned_letter .. [[" fruits ----]] )
for word in s:gmatch '%w+' do
    if word:sub( 1, 1 ) == banned_letter then
       goto continue2    -- I cannot reuse "continue" as label!!!
    end
    print( word )
::continue2::
end
---------------


So if the limit where per-block, it would be possible to reuse common
labels for common idioms.


-- Lorenzo



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

David Manura
In reply to this post by Josh Simmons
On Tue, Jun 21, 2011 at 11:15 PM, Josh Simmons <[hidden email]> wrote:
> "A label is visible in the entire block where it is defined (including
> nested blocks, but not nested functions). A function cannot have more
> than one label with a given name." Emphasis on the second sentence.

There are three parts, which I had to reread this a couple times,
probably due to the order in which it is written:

(1) A label is visible in the entire block where it is defined
    (including nested blocks, but not nested functions).

(2) A function cannot have more than one label with a given name.

(3) A goto may jump to any visible label as long as it does not enter
    into the scope of a local variable.

Part #2 is easy to understand.  To be more specific though, labels in
nested functions don't seem to count.

Part #3 depends on understanding part #1.  On first reading part #1,
it's not clear what "visibility" is implying (answer: nothing in
itself), especially when we then read part #2 and learn that an
invisible label can still cause a name conflict and then read part #3
and learn that there are some visible labels we cannot jump to.

Another way to say part #1+3, without using the term "visibility", is
that a goto may jump to any label directly attached to either the same
block or any block containing it up to the enclosing function,
provided the jump does not enter the scope of a local variable.

Yet another way to say it is that a goto may jump to any label inside
the containing function provided it does not enter the scope of a
block or local variable.  I like that.

Also, note: "scope of a local variable" is defined to end before any
labels at the end of a block.  This allows simulating continue: "while
f() do if g() then goto continue end; local x; ..... ; ::continue::
end" is ok.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Lorenzo Donati-2
On 22/06/2011 7.25, David Manura wrote:
> On Tue, Jun 21, 2011 at 11:15 PM, Josh Simmons<[hidden email]>  wrote:
>> "A label is visible in the entire block where it is defined (including
>> nested blocks, but not nested functions). A function cannot have more
>> than one label with a given name." Emphasis on the second sentence.
>
> There are three parts, which I had to reread this a couple times,
> probably due to the order in which it is written:

I agree, I found it a bit hard to read it too.

>
> (1) A label is visible in the entire block where it is defined
>      (including nested blocks, but not nested functions).
>
> (2) A function cannot have more than one label with a given name.
>
> (3) A goto may jump to any visible label as long as it does not enter
>      into the scope of a local variable.
>
> Part #2 is easy to understand.  To be more specific though, labels in
> nested functions don't seem to count.
>
> Part #3 depends on understanding part #1.  On first reading part #1,
> it's not clear what "visibility" is implying (answer: nothing in
> itself), especially when we then read part #2 and learn that an
> invisible label can still cause a name conflict and then read part #3
> and learn that there are some visible labels we cannot jump to.
>
> Another way to say part #1+3, without using the term "visibility", is
> that a goto may jump to any label directly attached to either the same
> block or any block containing it up to the enclosing function,
> provided the jump does not enter the scope of a local variable.
>
> Yet another way to say it is that a goto may jump to any label inside
> the containing function provided it does not enter the scope of a
> block or local variable.  I like that.
>
> Also, note: "scope of a local variable" is defined to end before any
> labels at the end of a block.  This allows simulating continue: "while
> f() do if g() then goto continue end; local x; ..... ; ::continue::
> end" is ok.

I was just thinking of it right now. I'm not a fan of continue, but I
find it really useful sometimes.

Now that the goto machinery is in place, wouldn't a "continue" keyword
be useful and easily introduced? If I remember well, Lua authors weren't
contrary to it in principle, but because of the incompatibilities with
"until".

Now this seems to work:

--------------
local s = "apple banana kiwi pear apricot plum mango \*
papaya blackberry coconut strawberry"

local banned_letter = "p"

local word, _
local pos = 0
repeat
    _, pos, word = s:find( '(%w+)', pos + 1 )
    if word and word:sub( 1, 1 ) == banned_letter then
       goto continue  -- or simply "continue" keyword
    end
    print( word )
    -- local foobar  -- this would generate an error, if uncommented
    ::continue::  -- hidden label if continue were introduced
until word ==  nil
--------------------

So continue could be translated internally to a such a goto. That is,
"continue" could be just syntactic sugar for such a goto. This solves
also the problem of continue bypassing a local var declaration: this
would generate an error in the same way now goto would generate one if,
after the "print" above, there were a local declaration.


-- Lorenzo


>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

dcharno
In reply to this post by Lorenzo Donati-2
On 06/22/2011 12:57 AM, Lorenzo Donati wrote:

> On 22/06/2011 0.21, Luiz Henrique de Figueiredo wrote:
>> Lua 5.2.0 (beta-rc2) is now available at
>> http://www.lua.org/work/lua-5.2.0-beta-rc2.tar.gz
>>
>
> [snip]
>
> I see that a constraint has been introduced so that a label cannot be
> repeated inside the same function.
>
> I've already argued on the other thread (5.2 beta-rc1) that I'd prefer a
> limit "per-block". There I motivated my preference with an use case for
> error management.
...
 > So if the limit where per-block, it would be possible to reuse common
 > labels for common idioms.

I gave up following the other goto thread so I must have missed the "per
function" label constraint.  It should really be "per block".

Its ashame. The goto syntax isn't easy on the eyes, but it was powerful
and allowed a reasonable workaround for standard patterns like continue.
  But this "per function" limit really blows that; what a pity.



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

David Manura
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Jun 21, 2011 at 6:21 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.2.0 (beta-rc2) is now available at

Do the new setlocale calls in ldo.c change thread safety assumptions
Lua?  http://stackoverflow.com/questions/4057319/is-setlocale-thread-safe-function

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Miles Bader-2
In reply to this post by dcharno
dcharno <[hidden email]> writes:
> Its ashame. The goto syntax isn't easy on the eyes, but it was powerful
> and allowed a reasonable workaround for standard patterns like
> continue. But this "per function" limit really blows that; what a pity.

Hmm, no it doesn't, it just forces users to pick meaningful names
instead of just "muh, whatever, I'll just use ::continue::" -- in other
words, the result is probably _better_ than a simple "continue" in most
cases...

[If continue were the sort of thing that gets used _a lot_ maybe this
would be too high a burden.  But it's not.]

-Miles

--
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

dcharno
On 06/22/2011 02:32 AM, Miles Bader wrote:

> dcharno<[hidden email]>  writes:
>> Its ashame. The goto syntax isn't easy on the eyes, but it was powerful
>> and allowed a reasonable workaround for standard patterns like
>> continue. But this "per function" limit really blows that; what a pity.
>
> Hmm, no it doesn't, it just forces users to pick meaningful names
> instead of just "muh, whatever, I'll just use ::continue::" -- in other
> words, the result is probably _better_ than a simple "continue" in most
> cases...
>
> [If continue were the sort of thing that gets used _a lot_ maybe this
> would be too high a burden.  But it's not.]

What's it to you if people want to "mindlessly" pick ::continue:: as
their label?  Pick a meaningful label for yourself.  What's it to you if
people use continue control structures?  Why is this so religious?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

David Kastrup
In reply to this post by Lorenzo Donati-2
Lorenzo Donati <[hidden email]> writes:

> I was just thinking of it right now. I'm not a fan of continue, but I
> find it really useful sometimes.
>
> Now that the goto machinery is in place, wouldn't a "continue" keyword
> be useful and easily introduced? If I remember well, Lua authors
> weren't contrary to it in principle, but because of the
> incompatibilities with "until".
>
> Now this seems to work:

>    ::continue::  -- hidden label if continue were introduced
> until word ==  nil

I mentioned this before: the purpose of "continue" is a short-circuit of
a loop before its regular completion.  A while-loop _starts_ with the
check of the loop condition as a prerequisite to its regular execution.
A repeat-loop _finishes_ with the check of the loop condition as a
_consequence_ of its regular execution.

For that reason, you want "continue"-like behavior to resume a
repeat-until loop _at_ _the_ _top_ of the loop body, not at the point
where the condition is checked, since the condition is a _product_ and
not a prerequisite of the regular execution, and continue short-circuits
the regular execution.

If you claim possibility for confusion: show me real existing code
(rather than theoretic speculation) using "continue" inside of "do
.. while".

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

steve donovan
In reply to this post by Luiz Henrique de Figueiredo
On Wed, Jun 22, 2011 at 12:21 AM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> All feedback welcome. Thanks.

Just an observation about the folly of depending on undocumented internals.

Previously people could hijack the existing file objects by packing
their own FILE* in the LUA_FILEHANDLE userdata, which was just FILE**.
 Now that userdata looks like this:

typedef struct LStream {
   FILE *f;  /* stream */
   lua_CFunction closef;  /* to close stream (NULL for closed streams) */
 } LStream;

(LuaJIT uses something similar)

I mention this because I think there's a need for a standard way for
extensions to create Lua file objects, or even on level of a
'io.fdopen' function that would create a file object from an existing
file-like handle.  One particular use case would be a Windows
extension wishing to provide a UTF-8 aware io.open, or to redefine
io.popen so it does not depend on the particular broken implementation
of the Windows CRT.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Jerome Vuarand
2011/6/22 steve donovan <[hidden email]>:

> On Wed, Jun 22, 2011 at 12:21 AM, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>> All feedback welcome. Thanks.
>
> Just an observation about the folly of depending on undocumented internals.
>
> Previously people could hijack the existing file objects by packing
> their own FILE* in the LUA_FILEHANDLE userdata, which was just FILE**.
>  Now that userdata looks like this:
>
> typedef struct LStream {
>   FILE *f;  /* stream */
>   lua_CFunction closef;  /* to close stream (NULL for closed streams) */
>  } LStream;
>
> (LuaJIT uses something similar)
>
> I mention this because I think there's a need for a standard way for
> extensions to create Lua file objects, or even on level of a
> 'io.fdopen' function that would create a file object from an existing
> file-like handle.  One particular use case would be a Windows
> extension wishing to provide a UTF-8 aware io.open, or to redefine
> io.popen so it does not depend on the particular broken implementation
> of the Windows CRT.

The API of the file objects is clearly defined in the manual, you can
implement a new function io.open that would return your own userdata
(or a table) with the right methods. If you properly override io.type
any Lua code will still work. That would only break C modules that
don't use the object methods like Lua code would, but rather decided
to assume they know the (undocumented) content of the file userdata
and called fread/fwrite directly.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

steve donovan
On Wed, Jun 22, 2011 at 10:52 AM, Jerome Vuarand
<[hidden email]> wrote:
> The API of the file objects is clearly defined in the manual, you can
> implement a new function io.open that would return your own userdata
> (or a table) with the right methods.

This is true, and it's the approach I took for a SciTE extension that
needed a robust popen. But it involves copying most of liolib.c, which
seems like overkill.  The suggested io.fdopen() would allow you to
pass your own open file handle (with an optional cleanup function?)
and let the existing io functionality do the rest.

As for undocumented, well this is exactly the point: continuing to
cast to FILE** can be a problem.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Alexandre Rion
In reply to this post by dcharno
I also think that labels should be per block. I think that the previous
behaviour was really natural once familiar with the lua synthax, avoid the
need of making the inventory of all the labels used in the function to know
how to called the next local-use label (such "continue"-like) and eventually
can lead to new possibilities since it's more general. The passage to labels
per function is just an extra-mechanism of protection against supposed
"mindless user" that doesn't have any reason to be:
- users don't need we take care of them with such limitations. They want to
learn and are supposed to be sufficiently open minded.
- the previous mechanism (as already stated) was really natural in the lua
context, using the same notions of scope than local variables, and would be
quickly adopted.
What's more, I don't see any improvement given by this modification since
only a limitation has been added without giving any new possibility, so it
seems me nonsense.
Actually, before that the goto was implemented by the Lua developers, the
way I used to imagine it was as it's now in beta-rc2, because well, I'm not
expert in theses things and it's the only way I know. But when I've seen the
implementation in beta-rc1, I've been really well surprised to see how they
had adapted this mechanism in a innovative and "Lua" way. So my personal
opinion is that I would prefer to see the previous implementation coming
back.



-----Message d'origine-----
From: dcharno
Sent: Wednesday, June 22, 2011 8:42 AM
Cc: Lua mailing list
Subject: Re: [ANN] Lua 5.2.0 (beta-rc2) now available

On 06/22/2011 02:32 AM, Miles Bader wrote:

> dcharno<[hidden email]>  writes:
>> Its ashame. The goto syntax isn't easy on the eyes, but it was powerful
>> and allowed a reasonable workaround for standard patterns like
>> continue. But this "per function" limit really blows that; what a pity.
>
> Hmm, no it doesn't, it just forces users to pick meaningful names
> instead of just "muh, whatever, I'll just use ::continue::" -- in other
> words, the result is probably _better_ than a simple "continue" in most
> cases...
>
> [If continue were the sort of thing that gets used _a lot_ maybe this
> would be too high a burden.  But it's not.]

What's it to you if people want to "mindlessly" pick ::continue:: as
their label?  Pick a meaningful label for yourself.  What's it to you if
people use continue control structures?  Why is this so religious?


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

David Kastrup
Alexandre Rion <[hidden email]> writes:

> I also think that labels should be per block.

+1

Local variables are per block.  This makes it possible to have
self-contained syntactical entities with minimal outside interaction.
function-local labels break this concept, and it is not clear to me how
this would affect label/goto outside of functions.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc2) now available

Patrick Rapin
In reply to this post by Luiz Henrique de Figueiredo
> All feedback welcome. Thanks.

Thank you for the introduction of bit32.extract and bit32.replace
functions in Lua 5.2.0-beta, like I had asked for.
Now it is possible for me to deprecate my custom "bit" library, since
there is now a standard one-to-one replacement.

I noticed a documentation incompleteness for both bit32.extract (n,
field, width) and bit32.replace (n, v, field, width).
Looking in the code, the width parameter is optional and defaulting to
1 (which is good), but the documentation doesn't mention it.

1234