Lua 5.3.0 beta now available | Hacker News Reader

Lua 5.3.0 beta now available

permalink.gmane.org

41 pointsdottrap21 comments

The big features for 5.3 are:

  - Basic UTF-8 library
  - Bitwise operators
  - Integers

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

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.

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/

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.

Lua 5.2 has bit operations too, but they are functions not operators.

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

There was previously a compile-time option to use integers instead of doubles.

yes, and it was a complete nightmare dealing with that from the C side sometimes :/... sooo much conditional type casting :(

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

Everything was floating-point up until now, which plays nicely with integers...but only until 2^53 or thereabouts.

Sounds like another, somewhat more popular language...

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.

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.

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.

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

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.

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.

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.

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

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.

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

Reply on news.ycombinator.com