Jump to content




Thoughts on Lua 5.3


24 replies to this topic

#1 PixelToast

  • Signature Abuser
  • 2,265 posts
  • Location3232235883

Posted 31 March 2014 - 12:22 AM

Posted Image


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 '='
Posted Image

#2 Kingdaro

    The Doctor

  • Members
  • 1,636 posts
  • Location'MURICA

Posted 31 March 2014 - 12:55 AM

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

#3 Symmetryc

  • Members
  • 434 posts

Posted 31 March 2014 - 01:01 AM

I really like it :D

#4 immibis

    Lua God

  • Members
  • 1,033 posts
  • LocationWellington, New Zealand

Posted 31 March 2014 - 01:03 AM

View PostKingdaro, on 31 March 2014 - 12: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?

#5 Kingdaro

    The Doctor

  • Members
  • 1,636 posts
  • Location'MURICA

Posted 31 March 2014 - 01:07 AM

View Postimmibis, on 31 March 2014 - 01: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?

#6 Shazz

  • Members
  • 175 posts

Posted 31 March 2014 - 01:15 AM

View PostKingdaro, on 31 March 2014 - 12: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.

#7 Symmetryc

  • Members
  • 434 posts

Posted 31 March 2014 - 01:17 AM

.= should work like this:
local a = {
  b = 5;
}
a .= "b"
print(a) --> 5
Just like how a.b would return 5 :D.

#8 Kingdaro

    The Doctor

  • Members
  • 1,636 posts
  • Location'MURICA

Posted 31 March 2014 - 01:20 AM

View PostShazz, on 31 March 2014 - 01: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.

View PostSymmetryc, on 31 March 2014 - 01: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.

#9 Shazz

  • Members
  • 175 posts

Posted 31 March 2014 - 01:21 AM

View PostSymmetryc, on 31 March 2014 - 01: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.

#10 Symmetryc

  • Members
  • 434 posts

Posted 31 March 2014 - 01:25 AM

View PostShazz, on 31 March 2014 - 01:21 AM, said:

View PostSymmetryc, on 31 March 2014 - 01: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.

Edited by Symmetryc, 31 March 2014 - 01:40 AM.


#11 Shazz

  • Members
  • 175 posts

Posted 31 March 2014 - 02:25 AM

View PostSymmetryc, on 31 March 2014 - 01:25 AM, said:

-snip-

Why not just:
local e = {os.pullEvent()}
print(e[2])

or

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

Edited by Shazz, 31 March 2014 - 09:12 PM.


#12 Symmetryc

  • Members
  • 434 posts

Posted 31 March 2014 - 02:45 AM

View PostShazz, on 31 March 2014 - 02:25 AM, said:

View PostSymmetryc, on 31 March 2014 - 01: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.

#13 PixelToast

  • Signature Abuser
  • 2,265 posts
  • Location3232235883

Posted 31 March 2014 - 08:11 PM

Here is how the integer system works:
Posted Image
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
Posted Image
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

#14 Shazz

  • Members
  • 175 posts

Posted 31 March 2014 - 09:12 PM

View PostSymmetryc, on 31 March 2014 - 02: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.

#15 Symmetryc

  • Members
  • 434 posts

Posted 01 April 2014 - 02:40 AM

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.

#16 Kingdaro

    The Doctor

  • Members
  • 1,636 posts
  • Location'MURICA

Posted 01 April 2014 - 05:51 AM

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

Edited by Kingdaro, 01 April 2014 - 05:51 AM.


#17 PixelToast

  • Signature Abuser
  • 2,265 posts
  • Location3232235883

Posted 01 April 2014 - 06:03 AM

View PostSymmetryc, on 01 April 2014 - 02: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?
Posted Image
thats right :D
i am loving the new syntax, it takes so much less time converting code from other languages

#18 PixelToast

  • Signature Abuser
  • 2,265 posts
  • Location3232235883

Posted 01 April 2014 - 06:17 AM

View PostKingdaro, on 01 April 2014 - 05: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

#19 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 01 April 2014 - 06:02 PM

View PostPixelToast, on 01 April 2014 - 06:03 AM, said:

work3 was just released and guess what they added?
Posted Image

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?

#20 Symmetryc

  • Members
  • 434 posts

Posted 01 April 2014 - 06:36 PM

View PostPixelToast, on 01 April 2014 - 06:03 AM, said:

View PostSymmetryc, on 01 April 2014 - 02: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)?

View PostPixelToast, on 01 April 2014 - 06:03 AM, said:

work3 was just released and guess what they added?
Posted Image
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

Edited by Symmetryc, 02 April 2014 - 12:59 AM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users