ocamlformat
ocamlformat copied to clipboard
Feature request: formatting of Printf like function
Is your feature request related to a problem? Please describe.
I'm not able to find a way to configure ocamlformat for formatting this as itself:
let f formatter x =
Printf.printf "I have a long message to tell you, but it is just %a"
formatter x
instead of
let f formatter x =
Printf.printf "I have a long message to tell you, but it is just %a" formatter
x
My coworker @lambdaxdotx doesn't want to use ocamlformat because the formatter and its argument are not together which makes such code hard to grasp. I agree even if the advantage of ocamlformat trump this defect for me.
Describe the solution you'd like
Perhaps we could recognize, the function Printf.printf (syntactically), parse the format string as in the compiler and know when newline should be avoided (between the argument of %a).
It would be even nicer if the function to recognize could be extended in the configuration (e.g Format.printf, Fmt.pf, ...)
This doesn't sound like a good idea to me. Many people open Printf, or alias it module P = Printf or do let printf = Printf.printf, or ... treating Printf.printf different from other function calls just seems too ad-hoc...
On one hand I completely agree it is ad-hoc, on the other hand the current state is very distracting. Since ocamlformat would still be idempotent with this, I think it is not problematic that they are treated differently. Already code that is the same semantically can be formatted differently because one use longer name than the other for example.
At the end instead of all the printing function being formatted differently than a human would do, it is only some of them.
I think there are two potential degrees of surprising behavior here. If all arguments consumed by format strings could be reliably identified and formatted knowing the association between functions consumed by %a and their arguments, then the potential surprise would be limited to users seeing ocamlformat magically treat printf-like functions specially. But if the functions that receive format strings cannot be reliably identified, then the potential confusion is much higher, where opening modules or adding wrappers would change the heuristics. The first seems ok to me, though I am slightly bothered by the fact that not all values of type _ format are string literals, while the second seems like a step too far.
I wonder if there is a good way to gather some data about how accurate a predictor successfully parsing as a nontrivial format string is of having type _ format. If that is very accurate, then that could be a path forward.
ocamlformat doesn't have type information (no?), so how could we use type as predictor?
I was thinking to try to parse strings as format strings, and then if successful use the resulting CamlinternalFormatBasics.format6 value to determine the argument grouping. I'm not sure of the details, so maybe this is not feasible. This would also potentially misidentify cases where strings parse as format strings but are not actually format strings.