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

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

On 19 August 2015 at 16:05, Stephan Hennig <sh-list@posteo.net> wrote:
>> Am 18.08.2015 um 16:54 schrieb John Hind:
>>
>>> 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)
>>
>> string.format is an alien within the string library.  A better place 
>> for that function were, e.g., the io library.  format() is not about 
>> manipulating strings but its purpose is type conversion in preparation 
>> of outputting values.
>
>I write stuff such as ("foo = %s:%d"):format(bla, num) all the time and I
think it's entirely logical that a function for 
>generating formatted strings is called string.format (also, I wish I lived
in a parallel universe where priorities were such 
>that I >could drop the parentheses around that literal string...).
>
>-- Hisham

My point here is that high level languages are supposed to be something you
can learn and use without having to consult a
reference guide all the time. Machine-code like terse arbitrary syntaxes
embedded within languages spoil this party. The
fact these have been inherited from C is not a good excuse - by this logic
Lua is unnecessary and we should all just use C!

I cannot actually think of a better replacement for regular expression
patterns (does not mean I have to like them!).

String formatters and string literal escapes can both be replaced by string
concatenation and conversion/production functions.
string.char is already adequate for generating strings of non-printable
bytes (although constants for the common
control codes like CR and LF would be useful). tostring could easily be
enhanced with optional parameters to control the
fill width, number of significant digits etc.

On the main point of my post, I was not suggesting string.pack etc. is
useless, just that is should be a separate (optional)
library. The situation could be recovered somewhat by moving them to a
sub-library in a future version enabling them to
be omitted without having to modify the string library source.

The use cases posited have been:

Marshalling between multiple Lua threads: here you have control of both
ends, so you do not need something this
sophisticated. I would tend to serialise the data to Lua for this. In any
case you will need some kind of multi-thread library
as well, so the marshalling facilities may as well be included in that (or
in a separate support library).

Reading/writing  proprietary binary file formats: This is surely a VERY
specialised requirement again arguing for the facility to be
in an optional library. As I pointed out in the OP, it is also quite legacy
since most modern code uses structured text
file formats. The bit-wise operators (which the Bloat Police quite rightly
approved!) make it relatively easy
to write this stuff in Lua anyway.

I must also point out that as currently implemented, we have a byte packing
facility not a bit packing facility which restricts
the use cases. You can pack more tightly than a structured text format
could, but not as tightly as possible.



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