00:11 <discocaml> <deepspacejohn> are locally abstract types (type a.) always suitable for universal quantification ('a.)? I've found that they give much better error messages compared to just universally quantified variables, and I haven't run into downsides yet.

00:12 <discocaml> <deepspacejohn> This would be for cases where I don't necessarily need a locally abstract type, but I do need universal quantification.

00:30 <discocaml> <._null._> I think there was something about polymorphic variants where locally abstract types can't work, but generally it's not an issue to always go for both

00:33 <discocaml> <barconstruction> @deepspacejohn this is just a restatement of what null said but somebody pointed out on reddit that when a function is supposed to be both recursive and polymorphic and the child function is called at a different type than the parent (I thiink like, traversing a heterogenous list or recursive evaluation of an expression in a language with multiple types) then you will have to explicitly annotate the function as polymorphic, if it's loc

00:34 <discocaml> <deepspacejohn> interesting and good to know. thank you both.

01:21 <discocaml> <._null._> The explicit universal quantification is usually the thing you want, because it forces polymorphism. Adding the locally abstract type can be useful for error messages and is not recommended against, except if you work with polymorphic variants. To be clear, `type a. _` is already sugar for the combination of explicit polymorphism (`'a. _`) and locally abstract types `(type a)`; it sounds like you take it as being separate from explicit polymo

01:33 <discocaml> <deepspacejohn> I’m mainly coming from experience working with mutually recursive functions where some need to be universally quantified, and it seems like locally abstract types are better at “forcing” it to be polymorphic. With just a universally quantified variable, a type error usually causes the compiler to infer it as not polymorphic and then raises the error message at the universally quantified variable. With a locally abstract type, the c

01:36 <discocaml> <deepspacejohn> With just a universally quantified variable, type errors turn into “this function is less general than…” messages which means I have to figure out why the compiler is inferring it differently than how I annotated it. Locally abstract types have errors that agree with the annotations

20:36 <discocaml> <doraent> Hey, has anyone here tried to read the ocaml version CTFP ? I am trying to read it to get some applications of CT, and I find it a bit confusing : ocaml snippets look super verbose/heavy (and could be way smaller), and some parts of the book are just missing ocamlness (every explanation is still haskell-focused, only ocaml code snippets are added). So I thought some parts of the book could be rewrited, and code snippets modified to make a tru

20:36 <discocaml> <doraent>

20:36 <discocaml> <doraent> PS : sorry for the terrible english

22:44 <masterbuilder> doraent: hmm, skimming through some examples now, I think you are right. I have only read the first few chapters of the original book so I'm not super familiar but these examples seem ridiculous to me. I wonder why it's written like this

22:45 <masterbuilder> it might be because in later chapters you need to use the module system more heavily to model the concepts the book talks about (which would be more straightforward in Haskell) and they just deciced to make the style homogenous right from the start? possibly

22:50 <masterbuilder> some of the examples are totally fine, there's just a few at the beginning that really stuck out as being overly complicated to me, there might be a specific reason, I guess you could open an issue on github and ask. and it might be a good idea to just work through the original in haskell/c++, I think ocaml will probably get in the way here honestly