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

[Stephan Hennig <sh-list@...>]

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.

Not that format() is bloat, to the contrary, the string library is bloat
if all you want to do is printing some numbers nicely aligned.  Using
format() pulls-in all the rest of the string library where you were
better off with the rest of the io library.[1]  Because a frequent
use-case of format() is

  io.write(string.format([...]))

Moving format() to io even invites for some short-cut like io.writef().

As far as I can see, in lstrlib.c, stdio.h is included to have
sprintf(), which is used by str_format() plus some companions only.[2]
In C, printf et al. are in stdio.  Which gives another hint that the Lua
io library could be a better place for format() than the string library.

Alternatively, as there's some relation to print(), type() and
tostring(), table _G could be a suitable place for format() as well.
tostringf() perhaps.  Extending tostring() to automatically act like
format() when multiple arguments are given won't work in the case of

  tostring('%s', nil)

unfortunately.

Best regards,
Stephan Hennig

[1] Even if you're not trying to build your own Lua binary with the
string library ripped-off, having to access the string table besides io
table might impact your CPU cache's hit rate.  Micro-optimization, sure,
but there's no reason to waste cache lines.

[2] It's years ago that I have coded in C, so that analysis might well
be wrong.