00:02 <gzar> yeah the performance is the primary reason i chose to learn ocaml

00:05 <gzar> I have a question though. Regarding named parameters. `let f x = x;; let g ~asd:10;;` returns a function, instead of 10. I returns a function, taking a function taking a named parameter, to which the value 10 is then passed. How come? I'm a bit puzzled at this, i kind of expected a type error.

00:06 <gzar> `let g = f ~asd:10` sorry

00:28 <discocaml> <contextfreebeer> https://v2.ocaml.org/manual/lablexamples.html#s%3Alabel-inference maybe relevant

10:05 <reynir> I have a function with a type ascription: ``let rec run : type a. (a, _ as 'err) t -> (a, 'err) result = ...`` <--- is it correct that I can write `(a, 'err) t` instead of `(a, _ as 'err) t`? I don't remember why I did `_ as 'err`

11:02 <discocaml> <Alistair> I'm playing around with cohttp 6.0.0~beta2, and I was wondering if `Connection.t` is deprecated, what are we supposed to use to as connection identifiers?

11:39 <octachron> reynir, that should be the same (the "... as 'err" is more useful when the `...` is not `_` or just another variable name).

11:46 <discocaml> <chrisarmstrong> Ungoogleable error message from the OCaml compiler: "Type declarations do not match...The first is abstract, but the second is a variant"

11:46 <discocaml> <chrisarmstrong>

11:46 <discocaml> <chrisarmstrong> I'm pretty sure I know why it's happening (I'm attempting to use the type definition in another module as the one to satisfy my interface with `type x = ModuleB.x`), but what does it mean?

11:48 <discocaml> <octachron> What part of the error message gives you trouble?

11:51 <discocaml> <chrisarmstrong> It's more I don't really understand what it's trying to tell me is wrong. I was able to work around the problem with `include ModuleB` instead of doing `type x = ModuleB.x`, because to me they seem to the same thing

11:52 <discocaml> <octachron> Those are the same thing, you cannot solve the error above by using `include moduleB`.

11:53 <discocaml> <octachron> The error is telling you that the type declaration in the implementation doesn't match the one in the interface .

11:54 <discocaml> <octachron> For instance `module M: sig type t = A | B end = struct type t end` gives you the error that you mentioned, with some more context.

12:00 <discocaml> <chrisarmstrong> What if they're defined with the same constructors? Are they still technically different?

12:06 <discocaml> <octachron> Ah, that's the case that can be solved by an include. `module M: sig type t = A | B end = struct type t = X.t end` is probably not what you want on both fronts:

12:07 <discocaml> <octachron> - First, you are exposing a new separate type `M.t` which is outside of `M` distinct from `X.t`.

12:08 <discocaml> <octachron> - Second, the declaration `type t = X.t` is creating an abbreviation for `X.t` which doesn't match the requirement from the signature.

12:09 <discocaml> <chrisarmstrong> What is an "abbreviation"?

12:09 <discocaml> <octachron> If you want to re-export a type declaration in another module, you can use `type t = X.t = A | B`

12:10 <discocaml> <octachron> An `abbreviation` is just an abbreviation for a type expression like `type int_pair = int * int`.

12:10 <discocaml> <octachron> where you are not declaring a new type but just giving an abbreviated name to a type expression.

12:13 <discocaml> <chrisarmstrong> is an abbreviation like aliasing in other languages?

12:14 <discocaml> <chrisarmstrong> The syntax above is quite strange to me, as writing `type t = X.t = A | B` is weird when X.t already has a type declaration

12:18 <discocaml> <octachron> An abbreviation is giving another name to an expression, this is similar to defining `let two = 1 + 1` at the variable level. `aliasing` generally means having an alternating name for a variable or a memory location.

12:18 <discocaml> <octachron> For the second variable, you can consider that the syntax is "giving a local reminder of the previously existing declaration".

12:21 <discocaml> <chrisarmstrong> Thanks - it's still looks strange but given how OCaml treats .mli files it sort of logically follows

17:50 <gzar> does ocamlopt warn you when a function is not tail-recursive?

17:51 <companion_cube> no, but you can use `[@tailcall]` to get a warning on non tailcall sites

18:07 <gzar> companion_cube: thanks, thats better than manually checking the binary

18:09 <discocaml> <contextfreebeer> tailcall is awesome and you should use it but if for some reason it's not available (like in another language or sth) you should inspect the flamegraph of a run of your program instead, non-tail recursion is super obvious

18:09 <discocaml> <contextfreebeer> very fast way to check

18:14 <gzar> not sure how I can get a flamegraph, and checking the binary is also pretty easy really, just look for Jxx instructions instead of CALL in the given function

18:15 <gzar> could be usefull to have a setting of sorts to tell ocaml to check by itself

18:15 <gzar> like a compiler flag, i mean

18:27 <discocaml> <contextfreebeer> gzar: ok, more than one way to skin a cat, it sounds to me like checking the assembly would be slower but it depends on the code I guess

18:28 <discocaml> <contextfreebeer> I use perf for basically all profiling and perf-flamegraph for making flamegraphs

18:28 <discocaml> <contextfreebeer> works great for ocaml

18:29 <discocaml> <contextfreebeer> hmm it's not called perf-flamegraph, I'm talking about this script https://github.com/brendangregg/FlameGraph, it's designed to work with perf

18:37 <gzar> @contextfreebeer I'll check it out. Have performance data is always good. But its possible to write a 1 line bash command to check for this too

18:51 <gzar> oog its that flamegraph, i know about that one

18:53 <gzar> ooh*