Re: [ANN] Lua BitOp 1.0.0 released

[Mike Pall <mikelu-0812@...>]

David Manura wrote:
> This looks great, Mike.  One thing though is that 'require "bit"'
> conflicts with the package name of lbitlib as currently used in
> LuaRocks and LuaDist.  Then again, does there remain any reason to use
> lbitlib over BitOp?  Of the various implementations, these two
> projects look similar enough in design to be combined[1].  (LuaBit
> also uses the package name "bit", but I don't think that is used as
> much.)

Lua BitOp has a superset of the functionality of all the other bit
libraries. It's intended as a drop-in replacement. In fact I've
released it because of the recent discussion about portability
problems with lbitlib. There's no point to install more than one
bit library, so there's no conflict over the module name (maybe a
package conflict in a distribution).

> Also, one quasi-convention in Perl is for the package name of a Perl
> reimplementation of a C Module to be postfixed by ::Perl.  So, there
> exists Compress::Zlib and Compress::Zlib::Perl.  Similarly, I would
> suggest that any Lua-only reimplementation of this interface be given
> the package name "bitlua" or something like that.

The hope is that with Lua 5.2 we get a "bit" library in the core
distribution. Consider the Lua BitOp docs, and in particular the
section on operational semantics and rationale as my contribution
to this effort.

> BTW, I had recently implemented the Lua-only bitwise op library
> (bit.numberlua) based on Roberto's approach in the link below, both of
> which are in the link below.  However, it currently uses non-negative
> Lua numbers as its underlying data type, so the semantics might not
> currently be identical to BitOp.

Well, I guess this is close to the least-efficient way to do bit
ops in pure Lua. ;-) And BTW: CRC calculations in software are
much faster with an 8 bit -> 32 bit lookup table.

> [1] http://lua-users.org/wiki/BitwiseOperators

I've added the list of functions for Lua BitOp.

--Mike