Inclusion of lpack in Lua? Suggestions for Lua's unpack()

[Majic <majic.one@...>]

Hello...

A friend of mine recently began trying to reverse-engineer the
[closed] Volano instant messenger protocol in Perl which relied
heavily on Perl's pack() and unpack() functions for dissecting binary
streams.  I wanted to rewrite his "framework" in Lua but could not
easily do so without the lpack module, linked here:
http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/5.1/lpack.tar.gz  I am in
no way affiliated with the author so I cannot speak for him, and I
must admit that I have not used it very much so far, but it is my
opinion that something like this will become necessary with the
inclusion of bitlib in 5.2.  If you do not come from a Perl
background, or are just not familiar with Perl's pack() and unpack()
the behavior can be read about at these links:
http://perldoc.perl.org/functions/pack.html and
http://perldoc.perl.org/functions/unpack.html

Regardless if you think adopting a new pack() and unpack() is a good
idea, Lua already has an unpack() and the semantics are quite
different.  Firstly, I believe I heard that redefining __length for
string and tables in 5.2 is acknowledged by functions relying on the
length operator.  This is semi-relevant to what I'm getting to,
because unpack() relies on the length operator to return the
iteritable keys, which I'm sure you all know. :)

I wanted to suggest that unpack() be moved to table.unpack() since the
"namespacing" seems to make more sense (at least to me).  I also
wanted to suggest that instead of relying on the length operator, it
could return all values in general.  Something like:

local sample = { ['key'] = 'value', 'value2' } unpack(sample) would
yield: return 'value', 'value2'

I hope that I have not upset anyone by this, as I have come across a
few strong opinions about the semantics of Lua when discussing it with
friends.  If anything, I would feel most strongly about *just* the
move from unpack() to table.unpack()

Regards :)