ocamlformat icon indicating copy to clipboard operation
ocamlformat copied to clipboard

Feature request: formatting of Printf like function

Open bobot opened this issue 4 years ago • 5 comments
trafficstars

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, ...)

bobot avatar Jul 22 '21 16:07 bobot

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...

nojb avatar Jul 23 '21 12:07 nojb

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.

bobot avatar Jul 23 '21 13:07 bobot

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.

jberdine avatar Aug 04 '21 21:08 jberdine

ocamlformat doesn't have type information (no?), so how could we use type as predictor?

bobot avatar Aug 16 '21 08:08 bobot

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.

jberdine avatar Aug 16 '21 15:08 jberdine