Re: Reported to the Bloat Police: string.pack, .unpack and .packsize!

[Patrick Donnelly <batrick@...>]

Hello John,

On Tue, Aug 18, 2015 at 10:54 AM, John Hind <john.hind@zen.co.uk> wrote:
> Good grief, how did this feature get past the Bloat Police?

Perhaps you were on your doughnut break?

> Good ideas have been poopood here because they involve a couple of extra
> lines of C and a few words of documentation, yet a massive 500 line system
> for a highly specialised use-case gets in! Not to mention yet another
> arbitrary syntax with zero learnability (to join such bug-inducing horrors
> as escapes in string literals,

Uh, who complains about string literal escapes???

> regular expression patterns

Just yesterday [1], Lua was complimented on their minimalistic and
effective pattern matching facilities.

> and string format
> codes)

Which largely mirror C, what??

> and what must be a huge increase in required test cases.

You make it sound like a quadratic increase. Import test cases used
for the predecessor struct/lpack libraries. Done.

> The only use-case I can think of for this which could be implemented in
> base-line Lua without other add-on libraries is reading and writing
> proprietary binary file formats, surely a legacy case in these days of data
> interchange by formatted text standards such as XML, Json and even Lua
> itself! Sure it will be useful for interop marshalling and protocol support,
> but those uses require add-on libraries anyway so pack/unpack may as well
> also be an add-on library. Does it even have a significant advantage over
> ad-hoc implementation in Lua, especially now bitwise operations are
> available?

Bit packing has been a woefully missed feature in Lua for a long time.
It has been regularly requested on the list because it's useful in
virtually all major applications of Lua.

> Given it can be justified at all, the feature should be more flexible. The
> byte orientation is unnecessarily restrictive: it should support any length
> of signed or unsigned integer from 1-bit

There is a bit library.

> up to the size of lua_Unsigned and
> it should not require these to be byte aligned.
> This would better support
> protocol and hardware register mapping.

You want bit alignment? Wow.

> And why do the codes have to be
> single letters? I envisage something like:
>
> "uint8,bool,bool,int32,float16,pad8,6string,string8"
>
> Where pad8 means pad to a byte boundary, 6string means string with a six-bit
> count prefix, string8 means string with an 8-bit zero terminator.

The bike shed is already painted.

[1] http://lua-users.org/lists/lua-l/2015-08/msg00175.html

-- 
Patrick Donnelly