llvm dev - Nov 2016 - RFC: General purpose type-safe formatting library

> On Nov 7, 2016, at 2:58 PM, Zachary Turner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> FWIW, if you're only ever formatting numbers and strings (which I agree
is likely a majority of use cases), the syntax should be very easy to remember. 
Most of the time you don't need to specify anything other than the
placeholder index.  In that respect I expect it to catch on very quickly as
there's really nothing to remember.
> 
> Only if you want to customize the behavior will you maybe have to look up
the syntax, and in that case you would have to do something equally funky with
printf (such as not using it and writing 4 lines of streaming stuff to an
ostream instead).
I haven’t looked at your most recent patch to see if you have already done this,
but it would be great to add a section about this new API to "Important and
useful LLVM APIs” in http://llvm.org/docs/ProgrammersManual.html
<http://llvm.org/docs/ProgrammersManual.html>.

-Chris
> 
> On Mon, Nov 7, 2016 at 2:47 PM Justin Bogner <mail at justinbogner.com
<mailto:mail at justinbogner.com>> wrote:
> James Y Knight via llvm-dev <llvm-dev at lists.llvm.org
<mailto:llvm-dev at lists.llvm.org>> writes:
> >> You might be able to hook up a template-specialization like
mechanic to the
> >> processing of %s (similar to my current approach), but it's
not obvious how
> >> you proceed from there to get custom format strings for individual
types.
> >> For example, a formatter which can print a TimeSpan in different
units
> >> depending on style options you pass in.  This is especially useful
when
> >> trying to print ranges where you often want to be able to specify
a
> >> different separator, or control the formatting of the underlying
type.
> >>  (e.g. it's not clear how you would elegantly format a range
of integers in
> >> hex using this style of approach).
> >>
> >
> > It is entirely unclear to me that putting everything in a format
string:
> >   formatv("Here's a range: {0:$[ + ]@[x]}", range);
> > is better than composing functions with usual function-call syntax,
e.g.
> > something like this:
> >   format("Here's a range: %s", Join(range, " +
", Formatter("%x")));
> >
> > I think that's the meat of the disagreement: I'd prefer to
just see a safe
> > printf-replacement; something that's able to basically drop-in
replace C
> > printf, nothing super fancy. I don't see the justification for
being able
> > to specify everything you'd ever want to be able to do directly in
a
> > complex format string language.
> >
> > On the other hand, you see value in being able to specify the entirety
of
> > the output in the format string, and aren't concerned about the
syntax
> > being new and complicated.
> >
> > That said -- it doesn't appear that my point of view is widely
held, and
> > that's fine -- this is a matter of opinion, not right or wrong.
So,
> > continue on. :)
> 
> FWIW, I'm also not entirely sold that we need a complex formatting
> language here. The printf modifiers are easy to remember and are good
> enough 90% of the time, whereas with something like this I feel like
I'd
> need to look up the syntax every time I used it.
> 
> Like James though, I'm fine with conceding to the majority on this one.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161107/ded5ee3d/attachment.html>

This is now done in the latest diff.  Thanks for the suggestion.

On Mon, Nov 7, 2016 at 10:45 PM Chris Lattner <clattner at apple.com>
wrote:
> On Nov 7, 2016, at 2:58 PM, Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> FWIW, if you're only ever formatting numbers and strings (which I agree
is
> likely a majority of use cases), the syntax should be very easy to
> remember.  Most of the time you don't need to specify anything other
than
> the placeholder index.  In that respect I expect it to catch on very
> quickly as there's really nothing to remember.
>
> Only if you want to customize the behavior will you maybe have to look up
> the syntax, and in that case you would have to do something equally funky
> with printf (such as not using it and writing 4 lines of streaming stuff to
> an ostream instead).
>
>
> I haven’t looked at your most recent patch to see if you have already done
> this, but it would be great to add a section about this new API to
> "Important and useful LLVM APIs” in
> http://llvm.org/docs/ProgrammersManual.html.
>
> -Chris
>
>
> On Mon, Nov 7, 2016 at 2:47 PM Justin Bogner <mail at
justinbogner.com>
> wrote:
>
> James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >> You might be able to hook up a template-specialization like
mechanic to
> the
> >> processing of %s (similar to my current approach), but it's
not obvious
> how
> >> you proceed from there to get custom format strings for individual
> types.
> >> For example, a formatter which can print a TimeSpan in different
units
> >> depending on style options you pass in.  This is especially useful
when
> >> trying to print ranges where you often want to be able to specify
a
> >> different separator, or control the formatting of the underlying
type.
> >>  (e.g. it's not clear how you would elegantly format a range
of
> integers in
> >> hex using this style of approach).
> >>
> >
> > It is entirely unclear to me that putting everything in a format
string:
> >   formatv("Here's a range: {0:$[ + ]@[x]}", range);
> > is better than composing functions with usual function-call syntax,
e.g.
> > something like this:
> >   format("Here's a range: %s", Join(range, " +
", Formatter("%x")));
> >
> > I think that's the meat of the disagreement: I'd prefer to
just see a
> safe
> > printf-replacement; something that's able to basically drop-in
replace C
> > printf, nothing super fancy. I don't see the justification for
being able
> > to specify everything you'd ever want to be able to do directly in
a
> > complex format string language.
> >
> > On the other hand, you see value in being able to specify the entirety
of
> > the output in the format string, and aren't concerned about the
syntax
> > being new and complicated.
> >
> > That said -- it doesn't appear that my point of view is widely
held, and
> > that's fine -- this is a matter of opinion, not right or wrong.
So,
> > continue on. :)
>
> FWIW, I'm also not entirely sold that we need a complex formatting
> language here. The printf modifiers are easy to remember and are good
> enough 90% of the time, whereas with something like this I feel like
I'd
> need to look up the syntax every time I used it.
>
> Like James though, I'm fine with conceding to the majority on this one.
>
> _______________________________________________
>
>
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161108/8006aee9/attachment-0001.html>

Will leave this up until this Friday before committing unless there are
further blockers.

On Tue, Nov 8, 2016 at 11:27 AM Zachary Turner <zturner at google.com>
wrote:
> This is now done in the latest diff.  Thanks for the suggestion.
>
> On Mon, Nov 7, 2016 at 10:45 PM Chris Lattner <clattner at apple.com>
wrote:
>
> On Nov 7, 2016, at 2:58 PM, Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> FWIW, if you're only ever formatting numbers and strings (which I agree
is
> likely a majority of use cases), the syntax should be very easy to
> remember.  Most of the time you don't need to specify anything other
than
> the placeholder index.  In that respect I expect it to catch on very
> quickly as there's really nothing to remember.
>
> Only if you want to customize the behavior will you maybe have to look up
> the syntax, and in that case you would have to do something equally funky
> with printf (such as not using it and writing 4 lines of streaming stuff to
> an ostream instead).
>
>
> I haven’t looked at your most recent patch to see if you have already done
> this, but it would be great to add a section about this new API to
> "Important and useful LLVM APIs” in
> http://llvm.org/docs/ProgrammersManual.html.
>
> -Chris
>
>
> On Mon, Nov 7, 2016 at 2:47 PM Justin Bogner <mail at
justinbogner.com>
> wrote:
>
> James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >> You might be able to hook up a template-specialization like
mechanic to
> the
> >> processing of %s (similar to my current approach), but it's
not obvious
> how
> >> you proceed from there to get custom format strings for individual
> types.
> >> For example, a formatter which can print a TimeSpan in different
units
> >> depending on style options you pass in.  This is especially useful
when
> >> trying to print ranges where you often want to be able to specify
a
> >> different separator, or control the formatting of the underlying
type.
> >>  (e.g. it's not clear how you would elegantly format a range
of
> integers in
> >> hex using this style of approach).
> >>
> >
> > It is entirely unclear to me that putting everything in a format
string:
> >   formatv("Here's a range: {0:$[ + ]@[x]}", range);
> > is better than composing functions with usual function-call syntax,
e.g.
> > something like this:
> >   format("Here's a range: %s", Join(range, " +
", Formatter("%x")));
> >
> > I think that's the meat of the disagreement: I'd prefer to
just see a
> safe
> > printf-replacement; something that's able to basically drop-in
replace C
> > printf, nothing super fancy. I don't see the justification for
being able
> > to specify everything you'd ever want to be able to do directly in
a
> > complex format string language.
> >
> > On the other hand, you see value in being able to specify the entirety
of
> > the output in the format string, and aren't concerned about the
syntax
> > being new and complicated.
> >
> > That said -- it doesn't appear that my point of view is widely
held, and
> > that's fine -- this is a matter of opinion, not right or wrong.
So,
> > continue on. :)
>
> FWIW, I'm also not entirely sold that we need a complex formatting
> language here. The printf modifiers are easy to remember and are good
> enough 90% of the time, whereas with something like this I feel like
I'd
> need to look up the syntax every time I used it.
>
> Like James though, I'm fine with conceding to the majority on this one.
>
> _______________________________________________
>
>
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161108/658fd8fd/attachment.html>