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

[Andrew Starks <andrew.starks@...>]

On Tue, Aug 18, 2015 at 9:54 AM, John Hind <john.hind@zen.co.uk> wrote:
> Good grief, how did this feature get past the Bloat Police?
>
> 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, regular expression patterns and string format
> codes) and what must be a huge increase in required test cases.
>
> 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?
>
> At the very least, this ought to be a sub-library like coroutines so it can
> be included/excluded independently of the rest of the string library.
>
> 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 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. 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.
>
> I'm genuinely baffled by the decision to include this: was it really
> considered to have a significantly more common use-case than all the stuff
> deprecated from the math library (which I am happy with, incidentally)?
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>

I think that message passing between Lua states is important and I
think these mechanisms will help people solve real problems: message
passing between Lua threads, being a primary example.

I like what I've played with and look forward to using it in the near
future. One thing that jumped out at me: no explicit support for
tables, nested or otherwise. I imagine that this is something that
would be layered on top of what is provided, but I have not puzzled
out what that layering would look like. It seems that I'm missing some
prior knowledge about how serialization is generally done.

A good exercise for the next PiL?

--Andrew