8 ms·
Lua 5.3: integers, bitwise operators, and a basic UTF-8 library
- fithisux 12y agoWowwwwwwwwwww
- arthursilva 12y agoFairly good news.
- arthursilva 12y agoWhy 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 12y agoThe 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 12y agoWell... I'll make sure to elaborate a little more next time. Edit: Thanks for the explanation.
- larme 12y agoI 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.
- justincormack 12y agoThey are much closer together though. 5.3 is a bigger change because of integers.
- sitkack 12y agoThere 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 12y agoI believe the main issue is there are too many such libraries and text is such an elementary piece of exchanged data.
- Dylan16807 12y agoutf-8 is trivial. There aren't major issues with processing code points. Having several libraries is fine.
- viach 12y agoIs it that hard to just make Lua another W3C standard, enable it in the browsers and make this world a bit better?
- sigzero 12y agoIt would probably be next to impossible at this point. Javascript is too entrenched.
- innguest 12y agoWould you be opposed if all browsers made Lua available for webpages? It does not seem impossible to me to add functionality to a browser to accept some other language to run. What you're talking about is how hard it would be to convince JS developers to stop using it. But no one is talking about that.
- jlarocco 12y agoI think that's already a feature of HTML, using the language="..." attribute of the script tag. Believe it or not, a long time ago, Javascript was actually the less bad option in web scripting. IE used language="vbscript" to allow web scripting in VBScript, which, AFAIK, was the only other language that became popular for scripting web pages.
- Aldo_MX 12y agoI would be opposed for one main reason: The extra overhead that supporting an additional language implies with hybrid websites (even if you disregard JS completely, external code like advertisements would introduce it). People can claim that the overhead is negligible with today's hardware, but this is not always the case, especially when you are trying to get as much performance as possible for a web-based game engine. We should be working hard to kill Flash and Java completely from the web, substituting them with modern and standard web technologies. I don't mind an obscure corporate website requiring their employees to install Flash or Java, but I do mind being bombarded with "please install Flash with Mc Affee unless you opt-out", because we are too lazy to display video without Flash. A better alternative to have Lua in the browser (at least in my opinion) is to support Mozilla's asm.js initiative, and compile Lua to LLVM/JS.
- philjohn 12y agoWow - 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 12y agoWell, Lua is only just now getting integers. Bitwise operations don't really make that much sense when you only have access to floats.
- dottrap 12y agoAdditional 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.
- aDevilInMe 12y agoThere have been a number of bit modules developed by 3rd party developers, including LuaJIT's Mike Pall, in addition to 5.2 which had bit functions. However, the bit functions were slow and a dog to use.
- fit2rule 12y agoThis 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 12y agoI 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.
- ctz 12y agoDisappointing 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 12y agoI 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 12y agoI'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 12y agoI 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 12y agoAh yes the C interface would be a problem.
- benhoyt 12y agoWhat'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?
- justincormack 12y agoYes. It is hard to interface with lots of C without 64 bit support. You can fudge it and hope it never happens but it is better to have full support.
- deleted 12y ago[deleted]
- ufo 12y agoIts one of the reasons. If you want more details you can check out this talk from Lua's main designer: 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 The main advantages of adding integers to Lua are: * For some things you need 2^64 bits, not just 2^53 (file handles, crypto algorithms with bitwise operations, etc) * Some embedded systems don't have hardware support for floating point (you could compile Lua with integers instead of double but it was very hacky) * It simplifies the C API. There are some things in the API and various internals in the implementation that benefit from separating integers and floating point numbers.
- benhoyt 12y agoThanks for the links -- slides were very helpful. This makes sense.
- speeder 12y agoAnother information from someone using Lua for years: Sometimes the hardware/OS/drivers/something else is buggy with floats... I once designed a game that needed integers for some things, and implemented it with Lua, on Windows machines it started to sometimes give VERY WRONG results (even in very short operations, like reporting that 5+5 == 11 or that 8+2 == 9, those are actual errors, not just short numbers to make typing easier). Later I found out it had to do with a infamous directX bug, where it changed the settings of the floating point units without permission, and sometimes this resulted into really, really, really funky floating point math, meaning that all math made with Lua in those cases maybe could be completely wrong. Back then when I found this (The issue, not the reason for it), many Lua devs kept telling me I as crazy or a troll, thankfully one guy in freenode.net #lua had the brilliance to tell me to check if it was the DX issue (and it was... the issue don't happened on Linux or OSX)
- ludamad 12y agoSadly 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).
- sitkack 12y agoI think having a world class JIT is somewhat of a distraction for regular Lua which is a world class language with an excellent interpreter. Lua literally runs everywhere with implementations that run in or on any platform you are currently using (Java, C#, C/C++, Javascript).
- ludamad 12y agoIt's nice to develop code with the possibility of plugging in LuaJIT though, and the language is indeed excellent - so much in fact that I can do with ignoring post 5.1 features
- acqq 12y agoI 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)?
- nickik 12y agoHe can if course make it fast, even very fast but conceptually its hard because he has focused so much work on making floating fast. He uses them as the basic element on the stack and hiddes pointers in the NaN. Ints dont have NaNs so that approche does not scale that well to more primitives. There are a range of compiler tricks that can make boxed math go fast as well.
- haberman 12y agoI 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."