
Lua 5.3.0 beta now available - dottrap
http://permalink.gmane.org/gmane.comp.lang.lua.general/113341
======
wbond
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
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
I don't think they are adding integers. According to the readme integers are
now 64bit by default.

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

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

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

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

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

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

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

