Re: printf is a crappy language in a crappy language (was Re: [OT] Lua community and Go language)

[Andres Perera <andres.p@...>]

On Wed, Aug 14, 2013 at 7:23 PM, Jay Carlson <nop@nop.com> wrote:
> tl;dr: if you have all the constraints C did 25 years ago, printf/scanf are reasonable. If you take Go's concrete syntax for expressing structured data as a given, using string patterns seem more ergonomic. I don't see why we should be constrained by either in 2013, but I don't have any concrete solution other than for Lua. E4X, RIP.
>
> On Aug 13, 2013, at 5:28 PM, William Ahern wrote:
>
>> On Tue, Aug 13, 2013 at 02:18:43AM -0400, Jay Carlson wrote:
>>> On Aug 8, 2013, at 9:37 AM, steve donovan wrote:
>>>
>>>> On Thu, Aug 8, 2013 at 3:20 PM, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:
>>>>> fmt.Println(time.Now().Format("2006-01-02 03:04"))
>>>
>>>> It is very .. eccentric. Rob Pike is very proud of this idea ;)
>>>
>>> It is a cute idea, but just like printf, it's a symptom of a lack of expressive power at compile-time.
>>> [...[
>>> Most C compilers these days have special mechanisms hooked up to the
>>> printf/scanf functions to warn of mismatches in type between the format
>>> string and the arguments. So there's a special case again: you can't write
>>> your own replacements with the same functionality, especially if you are
>>> in the -Werror camp, where warnings are treated as errors.
>>
>> You can get close. Using C99's variable argument macros and C11's _Restrict,
>> you can translate at compile time each argument to a pair of arguments--type
>> and value. This type information can then be used at run time by the printf
>> implementation.
>
> Hmm, _Generic? OK, there's a couple hours wasted:
>

> ===
> #define f_(X) _Generic((X), \
>   long double: fmt_long_double(X), \
>   double: fmt_double(X), \
>   unsigned int: fmt_unsigned_int(X), \
>   const char *: fmt_string(X)) (X)

then i guess i want to print an unsigned int always as %u, or another
size appropriate format? why associate a type that encodes signedness
and size (unsigned int) with a string representation of decimal (%u)
over octal (%o)?

people that try to come up with format-inducing printf() replacements,
where induction is based on argument type and the language doesn't
support typeclasses, end up causing a combinatorial explosion of types
whose only purpose is to define subtly distinct toprintf() methods

whats a *real* problem with printf() in a safe memory model runtime,
where you dont get segfaults in f("%s %s", a1) for reading a possibly
NULL pointer??

(type induction is separate issue; in a weakly typed language you are
already checking types for other purposes; why is this singled out??)