Lua 5.3.0 beta now available

http://permalink.gmane.org/gmane.comp.lang.lua.general/113341

by dottrap • 12 years ago

41 21 12 years ago

permalink.gmane.org

wbond• 12 years ago

The big features for 5.3 are:

  - Basic UTF-8 library
  - Bitwise operators
  - Integers

http://www.lua.org/work/doc/#changes

JasonFruit• 12 years 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• 12 years ago

I don't think they are adding integers. According to the readme integers are now 64bit by default.

otoburb• 12 years 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/

eslaught3• 12 years 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• 12 years 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.

eslaught3• 12 years 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

spc476• 12 years 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• 12 years 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• 12 years ago

I haven't but Lua is frequently held up as an example of an excellent code base.

groovy2shoes• 12 years 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.

haberman2• 12 years 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_reddi...

catwell• 12 years 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• 12 years 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.

Lua 5.3.0 beta now available

Related Stories