Re: boolean operators

[Glenn Maynard <glenn@...>]

On Wed, Sep 27, 2006 at 10:04:06AM -0400, Greg Falcon wrote:
> On 9/27/06, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

(It works terribly on systems that only have 32-bit hardware floating
point, though.)

> 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*.

Mimicing C operators doesn't seem integral to wrapping C interfaces.
I've never had to do integer division or modulus in Lua in order to
implement or use a Lua wrapper for a C class.  (For that matter, Lua's
mod operator is defined differently than C's.)

> 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.

Lua provides its standard libraries to avoid this; add math.idiv and
math.imod.

> 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.

"If it has this, it must have this too" seems empty.  If it's really
useful, you can argue for it on its own, independent merits.  If it's
not justified on its own merits, then "symmetry" is a bad reason; it's
saying "do it because it looks good".

-- 
Glenn Maynard