3 ms·

Lua 5.3.0 beta now available

41 points by dottrap 12y ago

wbond 12y ago
The big features for 5.3 are: - Basic UTF-8 library - Bitwise operators - Integers http://www.lua.org/work/doc/#changes http://www.lua.org/work/doc/#changes
- JasonFruit 12y ago
  Bitwise operators are a huge improvement in the language; many criticisms of Lua focus on the lack thereof — I think the phrase I remember compared writing low-level bit operations in Lua to "carving code out of raw silicon." It sounds funny, though, to have version 5.3 of a language add integers.
  - sigzero 12y ago
    I don't think they are adding integers. According to the readme integers are now 64bit by default.
    - koenigdavidmj 12y ago
      Everything was floating-point up until now, which plays nicely with integers...but only until 2^53 or thereabouts.
      - dragonwriter 12y ago
        Sounds like another, somewhat more popular language...
    - eslaught 12y ago
      Previously, all Lua numbers were doubles. You could fit a 32-bit int into a double without trouble, and maybe the interpreter would even have an optimization for that internally, but at least conceptually, Lua never distinguished between floating point and integer values (e.g. type(1.4) and type(4) would both produce "number").
    - astrobe_ 12y ago
      There was previously a compile-time option to use integers instead of doubles.
      - virtue3 12y ago
        yes, and it was a complete nightmare dealing with that from the C side sometimes :/... sooo much conditional type casting :(
  - otoburb 12y ago
    Prior to this release there was the option of using Mike Pall's (LuaJIT developer) BitOp C extension module[1] for Lua 5.1/5.2 if one wanted a cleaner way of performing bitwise operations. [1] http://bitop.luajit.org/ http://bitop.luajit.org/
    - justincormack 12y ago
      Lua 5.2 has bit operations too, but they are functions not operators.
    - haberman 12y ago
      It's unfortunate IMO that Lua didn't just adopt BitOp and its semantics. The different decisions made by the core Lua developers did not seem compelling to me. For example, one of the differences is that you can shift by a negative number with Lua (making the shift go in the opposite direction). Who ever needs to do that? This was all discussed at length on the lists, I don't have a link handy though.
eslaught 12y ago
So, with the Lua interpreter / LuaJIT divide, what's going to happen now? If LuaJIT continues to stick firmly to 5.1 compatibility it seems like they can't really avoid forking the language, which would be unfortunate.
- sswezey 12y ago
  Why would they have to fork the language instead of just being 5.1 compatible. There is nothing saying they have to be the most recent version compatible.
  - eslaught 12y ago
    Well, LuaJIT had already supported some of 5.2, just not all of it [1]. So I guess the issue is, how long can LuaJIT hold out on being 5.1 compatible while pulling in features from 5.2+ while not fragmenting the language? My (admittedly limited) understanding is that 5.2 was already not fully backwards compatible with 5.1, so if that trend continues, I just have a hard time seeing LuaJIT stay 5.1 compatible without effectively forking the language (even if they don't call it out as such). [1]: Here is one reference though it's not necessarily the best: http://lua-users.org/lists/lua-l/2012-01/msg00796.html http://lua-users.org/lists/lua-l/2012-01/msg00796.html
  - spc476 12y ago
    The major difference between Lua 5.1 and Lua 5.2 is the environment a function operates in and this effects globals and modules in a rather big way. You can change the "global environment" a Lua function operates in quite easily in both Lua 5.1 and 5.2, but the underlying implementation is different between the two, and Mike Pall, the writer of LuaJIT, does not care for the new way globals are handled. There might also be issues with supporting Lua 5.3's integer type [1] in LuaJIT (now you use the C FFI to handle 64-bit integers). At this point, it seems there are two distinct versions of Lua, Lua and LuaJIT. I have some modules I wrote that support both Lua 5.1 and Lua 5.2, so I can still use them with LuaJIT if need be, but it's a pain (conditional code in both C and Lua) and it will only get worse if Lua 5.3 comes out [3]. [1] Up to Lua 5.2, Lua only supported one type of number (internally, a double [2]). Lua 5.3 now supports a distinct integer type, which has its implications (doubles don't wrap; you now get x.0 where before you would get x when printed, etc). The reason for 64-bit integer support is that doubles only support integer operations up to 2^53 or so. [3] [2] Unless you changed the internal representation of numbers in Lua, an easy change to make in the Lua sources. [3] I already had to work around 64-bit integers in some code dealing with process limits on a 64-bit system and Lua 5.1/5.2.
pearjuice 12y ago
People keep laughing at PHP for being a joke language but has anyone ever looked at the Lua internals? Probably not, because you wouldn't make it out of that hell alive. I am amazed they still manage to add variable types and bitwise operators without completely overhauling the language.
- Avshalom 12y ago
  I haven't but Lua is frequently held up as an example of an excellent code base.
- groovy2shoes 12y ago
  What's so hellish about the Lua codebase? I've found it extremely understandable and hackable. The parser is a recursive descent, syntax-directed translator to bytecode. Adding new operators amounts to adding extra token checks to the expression parsing section of the code and generating the appropriate bytecode. The VM itself is even simpler, and adding a new 'type' is just a matter of adding the extra case to the Value union, a new discriminator for the tag, and a handful of extra functions for dealing with it. Sure it's a little complicated, but language implementation is a complicated topic. It's hard for me to imagine Lua's code being much simpler than it is. Not sure what Lua's internals have to do with PHP, though.
- haberman 12y ago
  Quite the opposite, Lua is one of the leanest and most efficient dynamic language implementations out there. Its design is actually really clean, if you take the time to learn it. Here is a tour guide of the code base, written by Mike Pall (author of LuaJIT, not Lua, but obviously quite familiar with the Lua code base): http://www.reddit.com/r/programming/comments/63hth/ask_reddit_which_oss_codebases_out_there_are_so/c02pxbp http://www.reddit.com/r/programming/comments/63hth/ask_reddi...
- catwell 12y ago
  PUC Lua is about 20k lines of ANSI C code. The "ANSI" part makes it a bit old-fashioned sometimes but it is very readable. Maybe you were thinking about the LuaJIT code base? That one is indeed very tricky, in part because a lot of it is in ASM and in part because the algorithms behind it are very tricky. I doubt anybody other than Mike Pall understands it all.
Houshalter 12y ago
Adding integer support is nice, though it sucks that numbers will be integer by default. It also sucks that they are removing some of the mathematical operations.

41 points by dottrap 12y ago

wbond 12y ago

The big features for 5.3 are: - Basic UTF-8 library - Bitwise operators - Integers http://www.lua.org/work/doc/#changes http://www.lua.org/work/doc/#changes

JasonFruit 12y ago
Bitwise operators are a huge improvement in the language; many criticisms of Lua focus on the lack thereof — I think the phrase I remember compared writing low-level bit operations in Lua to "carving code out of raw silicon." It sounds funny, though, to have version 5.3 of a language add integers.
- sigzero 12y ago
  I don't think they are adding integers. According to the readme integers are now 64bit by default.
  - koenigdavidmj 12y ago
    Everything was floating-point up until now, which plays nicely with integers...but only until 2^53 or thereabouts.
    - dragonwriter 12y ago
      Sounds like another, somewhat more popular language...
  - eslaught 12y ago
    Previously, all Lua numbers were doubles. You could fit a 32-bit int into a double without trouble, and maybe the interpreter would even have an optimization for that internally, but at least conceptually, Lua never distinguished between floating point and integer values (e.g. type(1.4) and type(4) would both produce "number").
  - astrobe_ 12y ago
    There was previously a compile-time option to use integers instead of doubles.
    - virtue3 12y ago
      yes, and it was a complete nightmare dealing with that from the C side sometimes :/... sooo much conditional type casting :(
- otoburb 12y ago
  Prior to this release there was the option of using Mike Pall's (LuaJIT developer) BitOp C extension module[1] for Lua 5.1/5.2 if one wanted a cleaner way of performing bitwise operations. [1] http://bitop.luajit.org/ http://bitop.luajit.org/
  - justincormack 12y ago
    Lua 5.2 has bit operations too, but they are functions not operators.
  - haberman 12y ago
    It's unfortunate IMO that Lua didn't just adopt BitOp and its semantics. The different decisions made by the core Lua developers did not seem compelling to me. For example, one of the differences is that you can shift by a negative number with Lua (making the shift go in the opposite direction). Who ever needs to do that? This was all discussed at length on the lists, I don't have a link handy though.

eslaught 12y ago

So, with the Lua interpreter / LuaJIT divide, what's going to happen now? If LuaJIT continues to stick firmly to 5.1 compatibility it seems like they can't really avoid forking the language, which would be unfortunate.

sswezey 12y ago
Why would they have to fork the language instead of just being 5.1 compatible. There is nothing saying they have to be the most recent version compatible.
- eslaught 12y ago
  Well, LuaJIT had already supported some of 5.2, just not all of it [1]. So I guess the issue is, how long can LuaJIT hold out on being 5.1 compatible while pulling in features from 5.2+ while not fragmenting the language? My (admittedly limited) understanding is that 5.2 was already not fully backwards compatible with 5.1, so if that trend continues, I just have a hard time seeing LuaJIT stay 5.1 compatible without effectively forking the language (even if they don't call it out as such). [1]: Here is one reference though it's not necessarily the best: http://lua-users.org/lists/lua-l/2012-01/msg00796.html http://lua-users.org/lists/lua-l/2012-01/msg00796.html
- spc476 12y ago
  The major difference between Lua 5.1 and Lua 5.2 is the environment a function operates in and this effects globals and modules in a rather big way. You can change the "global environment" a Lua function operates in quite easily in both Lua 5.1 and 5.2, but the underlying implementation is different between the two, and Mike Pall, the writer of LuaJIT, does not care for the new way globals are handled. There might also be issues with supporting Lua 5.3's integer type [1] in LuaJIT (now you use the C FFI to handle 64-bit integers). At this point, it seems there are two distinct versions of Lua, Lua and LuaJIT. I have some modules I wrote that support both Lua 5.1 and Lua 5.2, so I can still use them with LuaJIT if need be, but it's a pain (conditional code in both C and Lua) and it will only get worse if Lua 5.3 comes out [3]. [1] Up to Lua 5.2, Lua only supported one type of number (internally, a double [2]). Lua 5.3 now supports a distinct integer type, which has its implications (doubles don't wrap; you now get x.0 where before you would get x when printed, etc). The reason for 64-bit integer support is that doubles only support integer operations up to 2^53 or so. [3] [2] Unless you changed the internal representation of numbers in Lua, an easy change to make in the Lua sources. [3] I already had to work around 64-bit integers in some code dealing with process limits on a 64-bit system and Lua 5.1/5.2.

pearjuice 12y ago

People keep laughing at PHP for being a joke language but has anyone ever looked at the Lua internals? Probably not, because you wouldn't make it out of that hell alive. I am amazed they still manage to add variable types and bitwise operators without completely overhauling the language.

Avshalom 12y ago
I haven't but Lua is frequently held up as an example of an excellent code base.
groovy2shoes 12y ago
What's so hellish about the Lua codebase? I've found it extremely understandable and hackable. The parser is a recursive descent, syntax-directed translator to bytecode. Adding new operators amounts to adding extra token checks to the expression parsing section of the code and generating the appropriate bytecode. The VM itself is even simpler, and adding a new 'type' is just a matter of adding the extra case to the Value union, a new discriminator for the tag, and a handful of extra functions for dealing with it. Sure it's a little complicated, but language implementation is a complicated topic. It's hard for me to imagine Lua's code being much simpler than it is. Not sure what Lua's internals have to do with PHP, though.
haberman 12y ago
Quite the opposite, Lua is one of the leanest and most efficient dynamic language implementations out there. Its design is actually really clean, if you take the time to learn it. Here is a tour guide of the code base, written by Mike Pall (author of LuaJIT, not Lua, but obviously quite familiar with the Lua code base): http://www.reddit.com/r/programming/comments/63hth/ask_reddit_which_oss_codebases_out_there_are_so/c02pxbp http://www.reddit.com/r/programming/comments/63hth/ask_reddi...
catwell 12y ago
PUC Lua is about 20k lines of ANSI C code. The "ANSI" part makes it a bit old-fashioned sometimes but it is very readable. Maybe you were thinking about the LuaJIT code base? That one is indeed very tricky, in part because a lot of it is in ASM and in part because the algorithms behind it are very tricky. I doubt anybody other than Mike Pall understands it all.

Houshalter 12y ago

Adding integer support is nice, though it sucks that numbers will be integer by default. It also sucks that they are removing some of the mathematical operations.