[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Inclusion of lpack in Lua? Suggestions for Lua's unpack()
- From: David Manura <dm.lua@...>
- Date: Mon, 18 Jan 2010 22:13:11 -0500
On Sun, Jan 17, 2010 at 1:37 AM, Majic wrote:
> Perl's pack() and unpack() functions for dissecting binary
> streams. ... but it is my opinion that something like this will
> become necessary with the inclusion of bitlib in 5.2.
These are very useful functions. It's a fundamental need to
(en/de)code some binary stream. The need also comes up in FFI [1] and
was also mentioned in a similar way in LuaJIT. I wouldn't go as far
to call them "necessary" as in impossible not to have since you can
write them in Lua, and some programs using bitops might not use
packing/unpacking (but do most?). One would also need to decide which
encodings to support (128-bit floats?)
[1] http://alien.luaforge.net/
> 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'
Keys are unordered, unless you impose an ordering like next or
__pairs. It's not clear to me that such an implementation of unpack
would return elements in the order I would need them in. What is the
use case for this?