 |
lua-l archive |
|
|
||
|
On Jul 9, 2013 2:03 PM, "Jerome Vuarand" <jerome.vuarand@gmail.com> wrote:
>
> 2013/7/9 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
> >> > Currently, the problem is even worse, as many people use Lua without
> >> > floating-point numbers.
> >>
> >> I am one of them.
> >>
> >> For me, 5.3 appears to be a great step forward
> >
> > Finally, the voice of a silent majority? :)
>
> As far as I'm concerned, it is, regarding the integer addition. And
> I'd agree with your rationale ordering (64bits support on general
> purpose hardware being more important than limited platforms
> optimization). I'm a bit annoyed by the introduction of integers in my
> existing code when I don't add a .0 suffix to my constants, but I
> guess for my performance requirements some late conversions from
> integer to floats won't matter.
>
> But I'd rather keep it a very discreet feature. In other words, not
> use it as an argument to import features from other languages that are
> better kept in these other languages (in my opinion).
>
> 2013/7/9 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
> >> I suppose such data manipulation often requires treating ints as
> >> unsigned quantities, therefore a bit64 library would be necessary
> >> (in a previous post Roberto said its realization is probable).
> >
> > We are considering adding bitwise operations to Lua. After all, the main
> > reason Lua did not have them was that they were awkward as primitive
> > operations over floating-point numbers. With integer numbers, this
> > problem is gone.
>
> So far Lua has a syntax quite close to natural language, ie. readable
> without knowledge of other programming languages. That's because it's
> rather high level, as much as a small implementation can be. With
> reasonnable mathematical education, you can understand mathematical
> operators (with maybe the exception of ^, though it's a quite common
> way to indicate superscript in plain text) and function calls
> (assuming you keep your functions functional). With a bit a logical
> thinking, the boolean operators behave like the corresponding words in
> english (and apart maybe from precedence, I believe they translate
> well to many other languages).
>
> But as far as I know bitwise operations have no such ubiquitous
> notations (maybe uppercase NOT/AND/OR/XOR?). I think most programmers
> would understand C-like bitwise operators. But some users of Lua may
> not be familiar with them, and IMHO that would seriously impact the
> beauty of the language as it is. People that know C (or a derivative)
> can easily interface with some C code, which should do all the heavy
> bit mangling.
>
> In other words it feels a little too low level (like the goto
> feature), and the overlap with C, which Lua complements so well, may
> compromise some of the uniqueness of Lua.
>
To me this sounds like saying "Lua should be kept as simple as possible to be readable by non-programmers", and while I generally agree with keeping the syntax simple and readable, I draw the line at omitting commonly-used operators and constructs - especially if it means the only way to perform those operations is much uglier without.
True, not everyone needs bit operators, and not everyone understands them, but this hardly seems like a reason not to have them. People who don't need them don't suffer from having them (adding them wouldn't give a noticeable increase to Lua's size or execution time); those who don't understand them probably aren't looking at code that uses them (XOR doesn't come up often in business logic, for example), and if they are, they're not terribly difficult to understand - especially if they work the same as in other languages such as C. Those who do need bit operations will likely appreciate the much cleaner syntax.
As an example, I once had to implement some very hairy decompiled code in Lua, that looked like several lines of such lovely constructs as:
T = (a << 24) | 0x10000000 | (((d & 0xF) >> 4) << 8) | ((d & 0xF0) >> 8) << 16) | (s + 0x100000)
That's ugly enough in C, but try rewriting it with bit.band(), bit.bor() etc and it becomes a nightmare (and almost certainly gains a bug or two).
(I don't have my system working to look up what were the exact formulas; some of those shifts might not make sense in this made-up example, but such constructs existed in the original, shifting one way to mask off low bits, then the other way to combine the result with the rest of the data.)
One thing that worries me though is that Lua already uses the ^ operator for exponentiation. That's already tripped me up before, and if an XOR operator is added (which is also ^ in many languages), it's no doubt going to confuse people who expect one and get the other, regardless of whether ^ keeps its current meaning or becomes XOR. (In such languages exponentiation is usually ** or doesn't have its own operator.)