Re: buf lib (was: io.format)

["Soni L." <fakedme@...>]

On 19/08/15 04:05 PM, Stephan Hennig 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.
>
> 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.
Basically anything that deals with buffers is in stdio.

Maybe we should get a buf lib?

buf.format() for what string.format() currently does
buf.concat() for what table.concat() currently does
<etc?>
> 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.

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.