[all] Ocamlformat pre-commit hook

[Roman-Manevich]

I think it is a good idea to have a standard style throughout our OCaml code base.
Also, using ocamlformat would reduce the number of cosmetic code differences, making reviewing the code simpler and faster.
If testing is taking too long for you, you can commit while skipping testing like so: SKIP=make-test git commit -m "foo"
However, it is recommended that you do perform testing on every commit (unless you're squashing commit in which case, it is okay to test just once at the last commit in the sequence).

[HadrienRenaud]

Hi @Roman-Manevich,

While I think this is a good idea, I think this PR misses a few points:

1. Version specification: how ocamlformat formats code is dependent on its version. The fix suggested in its documentation is to write a .ocamlformat file at the root of the directory and write the version in it.
2. Incremental adoption: for the moment, IIRC, only the files in asllib are formatted regularly. Probably specifying a .ocamlformat-ignore file with all the folders apart from asllib would be good as a first solution.
3. Specific options in some files: asllib/Typing.ml, asllib/Interpreter.ml, and asllib/types.ml need 73-character-wide lines for inclusion into latex documents. Again, having a asllib/.ocamlformat with margin = 73 should fix the problem

[HadrienRenaud]

Hi @Roman-Manevich, could you check that reference docs are still building correctly, and that the layout is good enough?

More generally, could you review the PR?

[Roman-Manevich]

HI @HadrienRenaud. Sure, I'll review and make sure things work, but it may have to wait to next week.

[relokin]

I really like the idea of the -ignore files because it meant that any new file will be checked, should we do this for litmus, tools and jingle and internal as well?

[HadrienRenaud]

We can! It is just not my decision to take so I did not do it this way

[relokin]

LGTM, but I have a high level question.

It will be a bit annoying if our editors can't be configured to follow the same style. Essentially ocamlformat will be fighting the developers. Is there a way to configure popular editors to follow this style? I've seen people using vim, emacs and VS Code.

[HadrienRenaud]

It will be a bit annoying if our editors can't be configured to follow the same style. Essentially ocamlformat will be fighting the developers. Is there a way to configure popular editors to follow this style? I've seen people using vim, emacs and VS Code.

I don't know. The way I use ocamlformat is the following:

1. Write code, not caring about any style.
2. Run ocamlformat before committing or when I've finished my function/whatever.
3. Repeat
4. Run ocamlformat (i.e. dune fmt) just before commiting and running make test

That being said, there are a lot of editors which accept an external reformatter:

1. VSCode official ocaml extension supports ocamlformat natively (once it is installed)
2. If you're running emacs or vim, probably running dune fmt is just a few keystrokes away ...

[relokin]

It will be a bit annoying if our editors can't be configured to follow the same style. Essentially ocamlformat will be fighting the developers. Is there a way to configure popular editors to follow this style? I've seen people using vim, emacs and VS Code.

I don't know. The way I use ocamlformat is the following:

1. Write code, not caring about any style.

2. Run ocamlformat before committing or when I've finished my function/whatever.

3. Repeat

4. Run ocamlformat (i.e. `dune fmt`) just before commiting and running `make test`

That being said, there are a lot of editors which accept an external reformatter:

1. VSCode [official ocaml extension](https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform) supports `ocamlformat` natively (once it is installed)

2. If you're running emacs or vim, probably running `dune fmt` is just a few keystrokes away ...

Thanks @HadrienRenaud. That makes sense. I would vote for enabling it for other folders too. Not a blocker though if peolpe want to try it in a limited set of folders first.

[maranget]

Well I am not very keen on imposing some format on OCaml code.

We each code in slightly different styles and I see no strong benefit in uniformity here. Provided of course that we refrain from changing complete files for no other reason than style.

As an example. Hadrien tends to put the in keyword in a line of its own. I'd rather have in at the end of the last line of the bound expression. I see no compelling reason for Hadrien to adopt my style or for me to adopt Hadrien's style.

[relokin]

Well I am not very keen on imposing some format on OCaml code.

We each code in slightly different styles and I see no strong benefit in uniformity here. Provided of course that we refrain from changing complete files for no other reason than style.

As an example. Hadrien tends to put the in keyword in a line of its own. I'd rather have in at the end of the last line of the bound expression. I see no compelling reason for Hadrien to adopt my style or for me to adopt Hadrien's style.

I think this PR needs to be accepted by everyone, and for this reason I'm removing my approval.

Having said that imo, I am not attached to any particular style. I find it useful when there is a uniform style though whatever that is. It doesn't matter if a block of code is indented 4, 8 spaces or a tab, but it helps a lot identifying the block when it's indented with the same spacing.

For example, in this code:

let foo a =
  let b = a + 1 in
  let c = b * 2 in
  b - c

I would find it confusing if someone wrote:

let foo a =
  let b = a + 1 in
let c = b * 2 in
  b - c

and I don't know if this is ever intentional.

But let me be clear I don't care if a style enforces this:

let foo a =
  let b = a + 1 in
  let c = b * 2 in
  b - c

over this:

let foo a =
     let b = a + 1 in
     let c = b * 2 in
     b - c

or this

let foo a =
  let b = a + 1 in
  let c = b * 2
  in b - c

No concensus

[HadrienRenaud]

Given @maranget answer, I see two possible outcomes for this PR:

1. Dropping it entirely
2. Restricting it to asllib, with or without reformatting dune files.

Given that code in asllib has to be properly formatted because it is quoted in reference documents, I would be tempted to go for option 2.
What do you think @maranget?

[maranget]

Option 2 looks reasonable.

[HadrienRenaud]

This PR now implements option 2, with minimal noise.

Unless anybody has a different opinion, I'll merge as soon as #814 is merged.

[HadrienRenaud]

Thanks all it looks like it works as expected, I'm merging