
Lua 5.3: integers, bitwise operators, and a basic UTF-8 library - dottrap
http://www.lua.org/versions.html#5.3
======
larme
I hope luajit will backport the utf-8 library.

A little bit OT here but I always think the situation of lua 5.1/5.2 is just
like python2/python3. E.g. lots of applications' embedded lua version is still
5.1 (Lightroom, Max 7, WoW?, Codea on iPad). Some packages like Metalua still
only run on 5.1.

~~~
sitkack
There are a few utf-8 libs for lua, some in pure Lua.

[https://github.com/starwing/luautf8](https://github.com/starwing/luautf8)

[https://github.com/luapower/utf8/blob/master/utf8.lua](https://github.com/luapower/utf8/blob/master/utf8.lua)

~~~
vardump
I believe the main issue is there are too many such libraries and text is such
an elementary piece of exchanged data.

~~~
Dylan16807
utf-8 is trivial. There aren't major issues with processing code points.
Having several libraries is fine.

------
ludamad
Sadly though a huge Lua fan I tend to ignore any advancements not also made in
LuaJIT for pragmatic reasons. Full-width 64bit integers would be _very_ nice
but LuaJIT cannot do them sadly without boxing or widening its current 64bit
tagged value approach. I'd still like if LuaJIT implemented boxed 64bit
integers that worked properly with its tables (eg by interning the integers,
currently box identity comparisons for table lookup are awful).

~~~
acqq
I can't imagine that Mike Pall won't find a way to make LuaJit fast with the
current Lua features, together with full 64-bit integers.

Can you please elaborate (or give some link)?

~~~
haberman
I asked Mike about this a while ago. Here's what he said about the challenges
of it (this was a year ago, so I don't know if this represents his current
thinking or not):

"Using 64 bit integers all-over will definitely hurt tight loops on 32 bit
machines -- narrowing number ranges is very tricky for the compiler. Also, the
fact that int64_t is neither a subset nor a superset of a double is worrying.
This kills various optimizations and may give surprising results even in
simple mixed-type expressions."

------
benhoyt
What's the rationale for adding integers? I thought the rationale for not
having them was to keep the language simpler, and integers 2^53 and less can
be store exactly as a (64-bit) float anyway. Is the rationale for adding them
so Lua can have full support for 64-bit-wide integers and bitwise operations
at that width?

~~~
jws
_and integers 2^53 and less can be store exactly as a (64-bit) float anyway._

Until you divide them by three.

There is a time and a place for integer arithmetic. You could get there with
liberal use of truncation, but it reads better as native integer arithmetic.

The slope is slippery, time to resist or embrace native complex, rationals,
and quaternions… I only stop the list here because it is as much as I've ever
used in real world code.

~~~
JadeNB
When did you use quaternions? (Genuinely curious!)

~~~
jws
Minecraft-like game I wrote with my daughter. I discovered their use the hard
way after having suffered through without them. Any time you are freely
rotating a viewpoint or an object in 3D space, you will probably want
quaternions.

Do write some good test cases though that compare to someone else's
implementation. I accidentally wrote my multiplication backwards and didn't
catch it for a long time. I just had a vague feeling that something was wrong
every time I wrote rotation code.

------
philjohn
Wow - surprised it's only just getting bitwise operators ... are they not
commonly required in systems that tend to embed Lua?

Thinking about Redis bitmaps, they could be very useful when available in the
scripting context/

~~~
theseoafs
Well, Lua is only just now getting integers. Bitwise operations don't really
make that much sense when you only have access to floats.

~~~
dottrap
Additional clarification. The integer reason was the main reason it wasn't in
the language, but various libraries have always been available to do bitwise
operations. Lua 5.2 included a bitwise library as part of the standard library
(which is now redundant and deprecated).

As a library, there were edge cases such as what if you used the number as
floating point or what happens with 64-bit.

Now with integers, bitwise operations can be put directly into the language
instead as a library.

------
fit2rule
This is great news .. I'm looking forward to getting this integrated into the
latest MOAI client. The lack of utf-8 support up to now was definitely a
little frustrating .. going to be great to get that integrated and functional.

~~~
bungle
I wouldn't call it "utf8 support". It's barely a starting point. string.xxx
functions still work with single bytes, and there aren't equivalents on
utf8.xxx side.

------
viach
Is it that hard to just make Lua another W3C standard, enable it in the
browsers and make this world a bit better?

~~~
ackalker
Well as for simply supporting Lua in browsers, aside from the obvious
Emscripten/ASM.js way, which would work for practically all browsers which
support JavaScript, Lua can run as a PNaCl app in Chrome/Chromium, see:
[https://chrome.google.com/webstore/detail/lua/nkcnhkobblkmia...](https://chrome.google.com/webstore/detail/lua/nkcnhkobblkmiampcmimoemaeffjopph?hl=en)

Of course this is only a proof-of-concept which just runs a Lua REPL in the
browser. I wonder if it is possible (and if so, how hard it is) to make the
browser run <script language="lua"></script> code.

~~~
justincormack
You need to define a DOM interface to do anything useful, which is a fair
amount of work.

~~~
daurnimator
lua.vm.js can manipulate javascript objects. the only outstanding issue is
tracking garbage (lua closures can leak into javascript).

In regards to actually doing the DOM work, craig barnes is doing great work
over with lua-gumbo: [https://github.com/craigbarnes/lua-
gumbo](https://github.com/craigbarnes/lua-gumbo)

------
arthursilva
Fairly good news.

~~~
arthursilva
Why so many down-votes? The main changes can't be really backported to LuaJIT
as far as I know. Otherwise I'd write "great news", then your down-vote
warriors would be happy.

~~~
corysama
The HN community takes a rather strict approach when moderating comments that
contribute noise to the conversation. "Nice article!" comments are routinely
downvoted. As is sarcasm, witticisms, memes, references and other styles of
comments that occur frequently but do not contribute to the discussion. It's a
knowingly doomed attempt to hold back the flood of noise that covers Reddit.

~~~
arthursilva
Well... I'll make sure to elaborate a little more next time. Edit: Thanks for
the explanation.

------
fithisux
Wowwwwwwwwwww

------
ctz
Disappointing that Lua is going down the same broken road of having limited
integer types. But, then again, Lua was always about a small, simple base than
correctness at all costs.

~~~
justincormack
I think you could replace the integer type with an unbounded one fairly
easily. Lua is designed to have changes made and it already allows other sizes
of integer and float to be used.

~~~
SloopJon
I'd love to be proven wrong, but all Lua lets you do is typedef to another
built-in type. Swapping in something like Python's long type would not be a
simple matter.

~~~
dottrap
I think you would probably want to do it as a userdata and not as a language
mod.

Roberto addressed the idea of a infinite number type, but it has a lot of
downsides which are very un-Lua like, i.e. complicated, slow (no real
hardware), and interoperability problems with the C API (which is very
important to Lua).

video:
[https://www.youtube.com/watch?v=bjqNK1jA77M](https://www.youtube.com/watch?v=bjqNK1jA77M)
slides: [http://www.inf.puc-
rio.br/~roberto/talks/ws2014.pdf](http://www.inf.puc-
rio.br/~roberto/talks/ws2014.pdf)

~~~
justincormack
Ah yes the C interface would be a problem.

