06:14 <discocaml> <emiletrotignon> Because you put extra parenthesis wherever you have a doubt about priority, and then ocamlformat tells you which were necessary and which were not.

06:23 <discocaml> <darrenldl> but i still need to know about priority when i'm reading it again later though

06:41 <discocaml> <emiletrotignon> Thats a fair point. The idea I had is for cases where seeing it once or twice is enough to teach you.

06:44 <discocaml> <darrenldl> i don't disagree it is a good learning experience, just i really don't have the headspace to remember these things, and i still largely see it as removing my attempt at code clarity

06:45 <discocaml> <darrenldl> like you can get away without many parenthesis in a gigantic mathematical formula, but i would appreciate grouping terms with parenthesis as a reader even though they are technically extraneous

06:55 <discocaml> <emiletrotignon> ocamlformat does keep some extra parenthesis, its just quite hard to make it perfect because whether they are desirable depends a lot on context. I had math formulas in mind though.

07:01 <discocaml> <darrenldl> i'll gladly take an option to just remove the decision and keep everything for me still: i really don't care about the precedence ranking between `*>`, `<*`, `<|>`, `|>` and a some other random operators

07:01 <discocaml> <darrenldl> care about learning*

07:08 <discocaml> <emiletrotignon> Yeah its just very hard because of how the current codebase is structured. I tried to add parenthesis information in the datastructure we use for printing. This would allow what you advocate. Alas I did not succeed, it was quite hard for multiple reasons (one of them was that ocamlformat changes some concrete syntax which in some cases results in needing to add parenthesis). Currently, ocamlformat forgets all parenthesis from the input

07:10 <discocaml> <darrenldl> fair enough, looks much easier to just normalise AST to one without extraneous parenthesis

07:12 <discocaml> <darrenldl> ultimately not every user experience improvement is worth the engineering effort

10:27 <discocaml> <getzapped.> can i bind a type variable on the right side of a type definition? like

10:27 <discocaml> <getzapped.>

10:27 <discocaml> <getzapped.> ```ocaml

10:27 <discocaml> <getzapped.> type t = {compare : 'a -> 'a -> int; inner : 'a other_t}

10:27 <discocaml> <getzapped.> ```

10:31 <discocaml> <octachron> Yes, but it is probably not what you want.

10:32 <discocaml> <octachron> `type 'a t = { compare: 'a -> 'a -> int }` means a record of type `'a t` contains a compare function for `'a`.

10:32 <discocaml> <octachron> `type t = { compare: 'a. 'a -> 'a -> int }` means a record of type `t` contains a single compare function that works on any `'a`

10:33 <discocaml> <octachron> (there are no such function within the language)

10:34 <discocaml> <octachron> `type t = Any: { compare: 'a -> 'a -> int }` means a value of type t contains a `compare` for some unknown type `'a`.

10:34 <discocaml> <octachron> (there are many such functions, but it not possible to use any of them once boxed inside the `Any` constructor)

13:38 <discocaml> <getzapped.> my record also contains another field inner of 'a other_t. I want to store the compare function with the value so that i can pass it to compare_other_t, which is

13:38 <discocaml> <getzapped.> ('a -> 'a -> int) -> 'a other_t -> 'a other_t -> int

13:39 <discocaml> <getzapped.> i need the 'a of the compare to be the same 'a as 'a other_t, but i want to be able to store these values in a collection where the 'a for each record might be different

13:42 <discocaml> <getzapped.> i know what it does, i do not want a polymorphic compare, i want a compare stored with a value of its 'a in a record

13:43 <discocaml> <octachron> The third option might work in this case if knowing that the `'a` of compare and the one in `'a other_t` are the same is sufficient.

13:46 <discocaml> <deepspacejohn> if you need to store a type inside a record, then that might be a use case for first class modules.

13:47 <discocaml> <getzapped.> i am considering it, but is there much overhead with a packed module with a simulated "this" value inside of it over a record with a function and a value of a locally bound type?

13:49 <discocaml> <deepspacejohn> at runtime, no. the syntax and error messages can potentially get bigger though.

13:52 <discocaml> <octachron> For just a type, the GADT(+unboxing annotation) variant is likely to be lighter than first-class module in term of syntax.

13:52 <discocaml> <octachron> But both options are exactly the same at runtime.

17:38 <discocaml> <yawaramin> let-bindings work even better

17:38 <discocaml> <yawaramin> for your use case

17:38 <discocaml> <yawaramin> break up parts of the expression into named bindings

23:40 <discocaml> <uberpyro181> Hi, if I have a dune project I was wondering what the easiest way to create a "release build" would be

23:41 <discocaml> <uberpyro181> e.g. maybe compiling with Flambda, or anything else to improve performance

23:42 <discocaml> <uberpyro181> my application isn't performance critical so it's not that important, but since i'm distributing an executable it seemed like it might be the best thing to do

23:48 <discocaml> <eval.apply> `dune build --profile release` and and compiler flags with https://dune.readthedocs.io/en/latest/concepts/ocaml-flags.html

23:49 <companion_cube> With -p it's always a release build, or use `--profile=release` iirc