Add Fmt.{print_endline, prerr_endline}

[hcarty]

What do you think of adding

val Fmt.print_endline : ('a, Format.formatter, unit, unit) format4 -> 'a
val Fmt.print_endline : ('a, Format.formatter, unit, unit) format4 -> 'a

implemented as

let print_endline fmt = kstrf print_endline fmt
let prerr_endline fmt = kstrf prerr_endline fmt

potentially with better names.

I end up using these often in toplevel sessions and small throw-away scripts/programs when setting up Logs may be more code than it's worth.

[hcarty]

I'll create a PR if you are ok with the addition.

[dbuenzli]

Is it really worth the addition ? E.g. you can do equivalently:

Fmt.pr "bla@.";
Fmt.epr "bla@."

[hcarty]

I think it may be worth the addition, but probably not a good idea to implement as I wrote it. If I recall correctly mixing Format and non-Format output on a channel is a bad idea.

Would you be open to something along the lines of Fmt.(prl, eprl) implemented as something close to your example? Thinking mainly toward readability and accessibility for users who are not getting deep into format string nuance but want to take advantage of the formatting provided by Fmt and other libraries providing their own 'a Fmt.t values to use.

[dbuenzli]

That could be even Fmt.(pr_line, epr_line) but I'm not really fond on the idea. Users who are not deep into format string nuance will precisely use it for wrong purpose.

[dbuenzli]

@drup Do you have an opinion on this ?

[Drup]

Your implementation is certainly better than @hcarty, but I understand the concern. Pierre Weis would say that such function should not be provided (he recently removed a function with a similar issue, although more severe). I don't have such a strong opinion, but he has a point.

I think if novice users indeed forget to add @., it would be better to improve the documentation/tutorial to make sure they don't.

[Drup]

@dbuenzli Did you consider writing your own tutorial for format, in the style of your other libraries? We could probably host it in ocaml.org (since it's not limited to Fmt). Format's documentation is not great, we can only improve the situation.

[dbuenzli]

@dbuenzli Did you consider writing your own tutorial for format, in the style of your other libraries?

Given infinite time I would but I'm afraid this won't happen in the foreseable future. I thought that this one which is linked from fmt's doc as "required reading" was not that bad --- at least it's the one that made me understand how Format works, but I didn't reread for a long time.

[Drup]

That tutorial explains the boxing model, not the API and the format strings, which is what is really missing.

[hcarty]

I think that convenience functions would be useful for users to take advantage of library-provided formatting functions without having to fully understand or worry about format details like boxes. For example, Fmt.pr_line "%a" Fmt.(Dump.list string) ["a"; "b"; "c"]-like code is useful for debugging or exploratory use. A user does not need to know about the implementation internals to appreciate the utility of such an operation. Then, as they decide they want to write their own pp functions, the can pull back the curtain and learn how the magic happens.

Do you think such functionality (pr_line/epr_line) belongs outside of Fmt? I don't think these functions should generally be used in "real" code - Logs fills that role nicely - but I do think they have a useful place in the ecosystem.

[Drup]

@hcarty the problem is that novice users will also use it inside combinators, instead of doing something like Fmt.pr "%a@,". pr_line does indeed returns a newline, it also collapse all the current boxes and reset to the default indentation. This will result in broken layout when nested. This is why we are a bit wary of adding such combinators. Users who don't know they can use @. will also use pr_line wrongly. It's probably preferable to directly teach them how to use @..

[dbuenzli]

Maybe we could provide [e]pr_flush but this should rather map to "@?" which is not what @hcarty is after.

[hcarty]

I'm going to close this. While I think a print_endline-like set of functions would be useful I agree that the issues listed are serious enough to leave this alone.