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

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

Yes, I guess I must concede that a true pack()/unpack() for binary
streams would not be a necessity as you can just require() the module
whenever you want, it would just be nice to have it in the core
alongside bitlib for that greater flexibility... Also might make
writing string functions that support unicode completely possible from
Lua :)

In regards to the existing unpack(), I had forgotten about that... now
it makes sense that it only returns the pairs with numeric keys
because it knows how to order them. >.<  I personally haven't had a
need to return *every* value, it just seemed like there was a possible
use case missing...  Guess I"ll clam up about that as there's no
definitive need.. XD

On Mon, Jan 18, 2010 at 7:13 PM, David Manura <dm.lua@math2.org> wrote:
> 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?
>