Thoughts on Lua 5.3

Lua 5.3 is still in the "what the hell do we add" stage but you can find the source here: http://www.lua.org/work/
or windows binaries made with MinGW: https://dl.dropboxus.../lua53work2.zip

It is almost identical to 5.2 but has some major things we have all wanted like integers, bitwise operators, and utf8 support
the list is small but here are the changes from 5.2: http://www.lua.org/work/doc/#changes

Main changes:

• support for integers (64-bit by default)
• better support for small architectures ("Small Lua" with 32-bit numbers)
• bitwise operators
• basic utf-8 library
• utf-8 escapes in literal strings
• functions for packing/unpacking numbers
• userdata can have any Lua value as uservalue
• strip option in lua_dump/string.dump

Lua standalone interpreter:

• Can be used as calculator; no need to prefix with '='

I find it kind of silly that they're adding bitwise operators but not assignment operators (+=, -=, etc.). That and the whole float/int differentiation.

I really like it :D/>

Kingdaro, on 31 March 2014 - 01:55 AM said:

I find it kind of silly that they're adding bitwise operators but not assignment operators (+=, -=, etc.).

How are bitwise operators related to assignment operators, apart from both being operators?

immibis, on 31 March 2014 - 02:03 AM said:

How are bitwise operators related to assignment operators, apart from both being operators?

Because the former is something a lot of people I'm sure have wanted as a feature in Lua, and last I checked, minimal syntax was one of Lua's philosophies. Why suddenly break it? What makes bitwise operators so special? Was the bit32 library not enough?

Kingdaro, on 31 March 2014 - 01:55 AM said:

I find it kind of silly that they're adding bitwise operators but not assignment operators (+=, -=, etc.). That and the whole float/int differentiation.

I agree, I think +=, -=, ++, –, ..= (or .= ?) are pretty much essential.

.= should work like this:

local a = {
  b = 5;
}
a .= "b"
print(a) --> 5

Just like how a.b would return 5 :D/>.

Shazz, on 31 March 2014 - 02:15 AM said:

I agree, I think +=, -=, ++, –, ..= (or .= ?) are pretty much essential.

I'd be fine without ++ and –, as += 1 and -= 1 is good enough, as well as /= and *= of course.

Symmetryc, on 31 March 2014 - 02:17 AM said:

.= should work like this:

local a = {
  b = 5;
}
a .= "b"
print(a) --> 5

Just like how a.b would return 5 :D/>/>.

Interesting idea, but incredibly screwy, lol.

Symmetryc, on 31 March 2014 - 02:17 AM said:

.= should work like this:

local a = {
  b = 5;
}
a .= "b"
print(a) --> 5

Just like how a.b would return 5 :D/>.

I can't see any uses for that, I was thinking more for string concatenation.

Shazz, on 31 March 2014 - 02:21 AM said:

Symmetryc, on 31 March 2014 - 02:17 AM said:

.= should work like this:

local a = {
  b = 5;
}
a .= "b"
print(a) --> 5

Just like how a.b would return 5 :D/>.

I can't see any uses for that, I was thinking more for string concatenation.

It would be useful when you want to access just part of a table I suppose, e.g.

local e = os.pullEvent() --> {"char", "#"}
e .= 2
print(e) --> "#"

But yeah, there's not much point to it lol.

Edit: Also, better lambdas please :D/>

-- This
local f = @(@1 * @2)
-- Is the same as
local f2 = function(_x, _y) return _x * _y end

That probably isn't the best syntax for it, but that's basically what I, personally, want :P/>.

Symmetryc, on 31 March 2014 - 02:25 AM said:

-snip-

Why not just:

local e = {os.pullEvent()}
print(e[2])

or

local e = select(2, os.pullEvent())
print(e)

Shazz, on 31 March 2014 - 03:25 AM said:

Symmetryc, on 31 March 2014 - 02:25 AM said:

-snip-

Why not just:

local e = os.pullEvent()
print(e[2])

or

local e = select(2, os.pullEvent())
print(e)

Former doesn't work, you'd have to wrap os.pullEvent() in {}'s :P/>.

But as I said, I was just talking about what I thought ".=" should be for the lolz, it's not really feasible at all.

Here is how the integer system works:

numbers are ints if they dont have a decimal point, otherwise they are floats
this isnt compatability breaking though, the math operators automatically convert them
there is also the new // operator which does division on ints, basically math.floor(a/b)
the reason for this is that we can now divide huge numbers, ones that are too big for floats

also, all numbers are 64 bit, even when compiled 32 bit

here are all the new bitwise operators:

• band: a & b
• bor: a | b
• bxor: a ~ b
• bnot ~ a – not sure how this one works
• blshift: a << b – same as a*(2^b)
• brshift a >> b – same as a//(2^b)

i hope they add a+=b, a++, etc

Symmetryc, on 31 March 2014 - 03:45 AM said:

Former doesn't work, you'd have to wrap os.pullEvent() in {}'s :P/>.

Yeah, forgot to do that :)/> Fixed it now.

After messing around with it a bit more (using PixelToast's magnificent ^v bot) I feel that they should make values valid statements, such that:

5
5 + 10
5 * 10 << 4 % 7
"Hello".." World"

is valid Lua code.

This way we can overload the new operators and use them more effectively and such.

That reminds me, wouldn't they have to add like 6 new metamethods to accommodate the operators?

Symmetryc, on 01 April 2014 - 03:40 AM said:

After messing around with it a bit more (using PixelToast's magnificent ^v bot) I feel that they should make values valid statements, such that:

 5 5 + 10 5 * 10 << 4 % 7 "Hello".." World" 

is valid Lua code. This way we can overload the new operators and use them more effectively and such.

no. this would cause ambiguous syntax, which would potentially break current code
anyway,
work3 was just released and guess what they added?

thats right :D/>
i am loving the new syntax, it takes so much less time converting code from other languages

Kingdaro, on 01 April 2014 - 06:51 AM said:

That reminds me, wouldn't they have to add like 6 new metamethods to accommodate the operators?

yes, they already have those

PixelToast, on 01 April 2014 - 07:03 AM said:

work3 was just released and guess what they added?

Did you edit this screenshot? It looks like something is broken. You set a value, add one, subtract two, and add one again, yet end up with a different value than you started with?

PixelToast, on 01 April 2014 - 07:03 AM said:

Symmetryc, on 01 April 2014 - 03:40 AM said:

After messing around with it a bit more (using PixelToast's magnificent ^v bot) I feel that they should make values valid statements, such that:

 5 5 + 10 5 * 10 << 4 % 7 "Hello".." World" 

is valid Lua code. This way we can overload the new operators and use them more effectively and such.

no. this would cause ambiguous syntax, which would potentially break current code

I see how it could be ambiguous if you did something like:

print
"thing"

So, I suppose they should make it so that only value-expressions are valid statement, but not single values (if they were to implement this idea)?

PixelToast, on 01 April 2014 - 07:03 AM said:

work3 was just released and guess what they added?

thats right :D/>
i am loving the new syntax, it takes so much less time converting code from other languages

Wow, really nice syntax, this will definitely be helpful in the future.

Btw, for all who are seeing this, you really have to try it out for yourself, downloading Lua 5.3 work3 is a real eye-opening experience.
Download link

Kingdaro, on 31 March 2014 - 02:07 AM said:

immibis, on 31 March 2014 - 02:03 AM said:

How are bitwise operators related to assignment operators, apart from both being operators?

Because the former is something a lot of people I'm sure have wanted as a feature in Lua, and last I checked, minimal syntax was one of Lua's philosophies. Why suddenly break it? What makes bitwise operators so special? Was the bit32 library not enough?

I don't understand that: you're saying one of lua's philosophies is a minimalized syntax, but isn't num >> bitstoshift much more minimalized than calling bit32.brshift(num, bitstoshift)?

It is, but x += y / x -= y is also more minimalistic then x = x + y / x = x - y: and they're not adding that, apparently. It's a bit odd when you consider that bitshifts aren't a common operation by comparison.

ardera, on 02 April 2014 - 04:36 PM said:

I don't understand that: you're saying one of lua's philosophies is a minimalized syntax, but isn't num >> bitstoshift much more minimalized than calling bit32.brshift(num, bitstoshift)?

Minimalism is not equivalent to less typing. Minimalism is simply using one of lua's provided constructs, a function, instead of hardcoding a syntax into the language, a new construct. It's the same as splitting the table type into an array, a hashmap, and other data structures, which is stupid when a table does the job of all of these nicely.

want a minimal typing bitshift, multiply or divide by a power of 2. Terrible idea normally though, when implemented in hardware a multiply or divide operation takes alot longer than a shift operation, dunno how the lua VM or bit32 libraries would handle this.

6677, on 03 April 2014 - 10:01 AM said:

want a minimal typing bitshift, multiply or divide by a power of 2. Terrible idea normally though, when implemented in hardware a multiply or divide operation takes alot longer than a shift operation, dunno how the lua VM or bit32 libraries would handle this.

i never use the bshift functions, math is faster 90% of the time
these new operators make bit operatrions faster and the integers make it even faster because there are no float conversions