Re: boolean operators

["Greg Falcon" <veloso@...>]

On 9/27/06, Glenn Maynard <glenn@zewt.org> wrote:
> At the cost of being repetitive, is there a reason for wanting this, other
> than performance (discussed elsewhere)?  It just seems like there's a whole
> lot of calls for more and more operators in Lua these days--on the tail of
> someone asking for a table append operator comes the bitwise operator
> thread, and then this.  With an operator for every operation that "inline"
> would be useful for in C, there will be a lot of operators.

As long as Lua is used to wrap C interfaces, there's going to be
feature requests addressing the issues that the differences between C
and Lua cause.

It took me a while to come to terms with doubles being the only
numeric type in a default Lua build, but now I'm convinced the
simplicity that that buys you is worth the costs.  A IEEE double can
store any int32 without loss, which is good, because integers are
still important.  Lua doesn't even try to pretend they're not -- for
example, it will use optimizations when storing tables with integer
keys, and it provides functions like lua_tointeger in the C API.

This typically works well.  Add, subtract, multiply two Lua
"integers", and so long as the result wouldn't overflow an int32, the
result you get is the same as you would get in 32-bit integer
arithmetic.  But this doesn't work with division, and bitwise
manipulation operations are nowhere to be found.  This especially
hurts since these operators are well established in C, and wrapping C
interfaces cleanly is what Lua *does*.

Integer division seems especially desireable because % behaves well
with integers, and it's weird to have easy access to integer remainder
but not to integer division.

Of course applications embedding Lua can provide functions that do
these operations, but now each Lua-powered product provides a
different set of functions for doing "primitive" operations.  Maybe
that's not the worst outcome in the world; part of what makes Lua so
cool is how small it is.

That said, if stock Lua decided to add integer division, it seems
clear to me that it must add either // or \ as an operator -- these
operators are used for this purpose in other languages, and Lua has
already set a precedent here with the % operator that it should follow
for symmetry's sake.  Bitwise operations might be added as operators,
or as a family of functions in math.int, or something else.

Perhaps providing functions in math.int and allowing the user to
specify custom infix operators is the best of both worlds.  __pow and
^ showed that this could work, and custom infix operators seems to fit
the philosophy of giving the user a framework with which to implement
various styles of programming.  But now I'm rambling.

My $0.02,
Greg F