01:45 <discocaml> <contificate> and you eventually run out of interesting topics and sell out

01:46 <discocaml> <contificate> start producing slop with "pondering emoji" thumbnails, where you discuss inheritance vs composition and cite Uncle Bob et al (2025)

01:51 <discocaml> <cod1r> there are tech content creators that just talk about "tech news"

01:51 <discocaml> <cod1r> even if they aren't subject matter experts

05:45 <discocaml> <aguluman> 😶

11:35 <discocaml> <gooby_diatonic> Is it good practice to use `modules_without_implementation` with dune? In one of my executable files I want to be able to have a few modules from a library with the same signature, which would be passed to a function as first class modules depending on some condition, so I need to add a signature for them. I thought I'd define that signature in a separate `mli` file, but now I'm questioning if that's good practice or not

12:37 <companion_cube> just use a .ml

13:38 <discocaml> <._null._> So you have a ml file with `module type S = sig ... end` *and* the accompanying mli file which is a carbon copy of the ml file?

13:41 <companion_cube> I just use a .ml without .mli in this case

13:42 <companion_cube> and silence the stupid warning

13:44 <discocaml> <gooby_diatonic> Honestly I've always found it a bit weird that the convention is to create a mli file for absolutely every ml file, as opposed to creating mli files when needed

13:45 <companion_cube> conventions can be stupid too :p

13:46 <companion_cube> I think there's a good balance

13:46 <companion_cube> also since, err, 4.08 ? you can do `open struct … end` to write private stuff in a .ml-only module

13:46 <companion_cube> that + type annotations means it's often nice to just have a .ml if most of it is public

13:46 <companion_cube> simple types, and functions around these, no complex invariants

13:47 <discocaml> <gooby_diatonic> Elegant

13:48 <companion_cube> (I annotate types anyway so it's kind of redundant to have a .mli, except in cases where the .ml is big but its .mli would be super short)

13:49 <discocaml> <diligentclerk> never heard of `open struct ... end`. that's really nice.

13:50 <companion_cube> yeah it's a nice trick

13:51 <discocaml> <gooby_diatonic> I annotate just to get `merlin-destruct` to work, then I remove the annotations 8)

13:52 <discocaml> <deepspacejohn> > except in cases where the .ml is big but its .mli would be super short

13:52 <discocaml> <deepspacejohn> I'm afraid this is 99% of cases for the code I write.

13:53 <discocaml> <deepspacejohn> It would be nice if type annotations in ml and mli had exactly the same meaning, i.e. were both universally quantified

14:01 <companion_cube> @gooby_diatonic noooo, keep them!

14:01 <companion_cube> they make code more readable :/

14:03 <discocaml> <gooby_diatonic> companion_cube: I agree, it's just that in OCaml I don't really like how either style of inline annotation works, although I think I might just give in and annotate non-obvious things with `let f : ... = fun ... -> ...` from now on

14:04 <discocaml> <gooby_diatonic> Since I noticed some things are very confusing without annotations, and I can avoid opening modules when matching on variants from them with a type annotation I believe

14:04 <discocaml> <gooby_diatonic> But I wish OCaml had Haskell-style annotations tbh

14:07 <companion_cube> `let f (x:a) (y:b) : c = ...` is nicer imho

14:10 <discocaml> <gooby_diatonic> I feel like I've had issues with it before but I can't remember what it was :7 I think when I had to do a `type a.`, and I happened to be writing a lot of that. But maybe I'll give it a go in non-GADT situations and see if it starts getting too verbose or not

14:18 <discocaml> <deepspacejohn> IIRC `: type a.` is necessary for certain recursive functions

14:21 <discocaml> <froyo> in the gadts `cast` example in the manual it's used unnecessarily

14:22 <companion_cube> sure, it's pretty rare though

14:22 <discocaml> <froyo> iirc the manual does say it is needed for polymorphic recursion, but using it outside of that can make its utility appear a little fuzzy

14:22 <companion_cube> I'd keep this only for gnarly, localized GADT stuff

14:22 <companion_cube> (GADT stuff needs to be localized anyway for sanity)

18:57 <discocaml> <dubious245> I'd love to just write a function signature (with holes) above the top level let bind rather than interspersing the type annotations into the let binding.

19:03 <discocaml> <deepspacejohn> It's not above the signature, but you can put "holes" as `_` in function annotations: `let f: int -> _ -> string -> _ -> blah = fun ...`

19:04 <discocaml> <deepspacejohn> I do that when I need polymorphic recursion but don't want to annotate the whole function, e.g. `let rec f : 'a. 'a -> _ = fun ...`

19:05 <discocaml> <deepspacejohn> `_` is just a type variable like `'a` except without giving it a name.

21:12 <discocaml> <diligentclerk> through networking I got put in touch with a guy who wants to make a convenient, easy to use tool for formal verification of models for distributed and concurrent system, part of the tool is kind of a compiler from the language for writing the model spec into the internal representation for finite model checking

21:15 <discocaml> <diligentclerk> and he's writing it in Go, which took me by surprise a little bit lol. He doesn't even love Go, he says it's not a very good language and refactoring is a pain. The only thing he seemed to like is the fast compilation and good performance. It shines on small projects. It surprises me when somebody in the formal methods community would reach for Go for a project instead of something with more influence from PL theory and bindings.

21:30 <discocaml> <froyo> and the pros he mentioned are already in ocaml, perhaps to a better degree

23:35 <companion_cube> Go has a better stdlib and static compilation story, but static analysis is one of these niches where ocaml actually does shine