Re: io.format (was: Reported to the Bloat Police: string.pack, .unpack and .packsize!)

["John Hind" <john.hind@...>]

> Responding to (the Great) Sean Conner, Thu, 20 Aug 2015 12:47:14 -0400:

>  When this first came up, I was wondering where you (John Hind) have been.

>Lua 5.3 was announced in July 2013, released in January 2015 and *NOW* you
>realize the string library has been expanded?

Having a life! I fully realise I am not a full-time member of the Bloat
Police and
I never expected my input to immediately cause pack etc to be removed
again! For academic reasons, I just wanted to understand the rationale and
the use cases for this. So far I've seen a lot of hand-waving but no
convincing
use case compelling enough to justify this being part of the language rather
than an add-on library. I had the same problem with hexadecimal float
literals in the last release, but was convinced by the serialisation-to-lua
use
case, which I'd not thought of, but now use all the time. Best result I can 
reasonably hope for (ed: this was 'expect' originally!) is the sub-library 
proposal which is completely cost-free.

>  I'm not sure what your point is here.  Yes, this:
>
>	syslog('emergency',"%s stat(%q) = %s",dbtype,conf.file,errno[err])
>
>could be replaced with:
>
>	syslog('emergency',dbtype .. ' stat("' .. conf.file .. '") = ' ..
errno[err])

I really could not have come up with a better example myself! Frankly the
second
Version "expresses intent" *much* more clearly than the first. I would have
to
look up "%q" in a reference manual and the whole pattern concept is opaque
unless you are steeped in "C". In the second version all you need to know is
the meaning of ".." which is easily guessable from context. Also you do not
have to worry about accidental escapes in the string literals (except for
quote
marks of course, which would remain a complexity).

>  One use case that comes up from time to time that you haven't covered is
>moving data from one Lua state on one computer to another Lua state on
>another computer (that may very well be a different architecture).  Yes,
>networking will probably be needed, but you don't need a multi-threaded
>library for this case.

A good case for serialising to Lua. As you say you need at least one other
Library so pack/unpack  may as well be an external library too.

 >I was unaware that ZIP files were a proprietary binary format.  I wonder
>whose intellectual property I'm violating by decoding DNS packets or CBOR
>formatted data.

This is a nit-pick - of course I realise there are non-proprietary binary
formats
too! And good luck with reading or writing ZIP files using Lua 5.3!

>In Lua 5.1, to read in a 32-bit value from network byte
>order to native order, I have the following code:

I will not quote the whole thing, but what you left out was the
implementation
using 5.3 bit-wise shift operators which is clear, straight-forward and
efficient and
"expresses intent" much more clearly than pack/unpack with its arbitrary
pattern syntax.

>Bit packing might cause even more bloat.  

That is a challenge - bit packing in less than 500 lines of C! I'll give it
a go when I
Get a moment. Also fun would be to do it in Lua with bit-wise operators. But

I never said it should be other than an add-on library!



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus