00:01 <discocaml> <akhilindurti> wondering if there's some tool that can detect strongly connected components among a bunch of `let rec ... and` bindings

00:04 <discocaml> <akhilindurti> i'm finding let bindings make it tedious to move code around, so i'm sticking everything in a `let-rec`. i may want to break it up in the future once the code is stabilized

00:04 <discocaml> <contextfreebeer> all of your functions are "mutually recursive"?

00:06 <discocaml> <akhilindurti> yeah it's the easiest way right now to not keep getting `"unbound value foo"` errors when editing code to call functions i happened to define later in the file

00:06 <discocaml> <contextfreebeer> well yeah but...

00:06 <discocaml> <contextfreebeer> I know it's annoying but still

00:44 <discocaml> <Kali> can't you just... define them in order?

00:45 <discocaml> <Kali> that can be an easy way to introduce bugs

00:52 <discocaml> <akhilindurti> in this case that would mean hoisting functions up to re-sort them in dependency order

00:53 <discocaml> <akhilindurti> it happened often enough that it got tedious

00:53 <discocaml> <akhilindurti> probably cause i refactor a lot

00:55 <discocaml> <akhilindurti> but yeah, i'm less concerned about bugs rn cause i'm prototyping

05:06 <discocaml> <sim642> How are let rec-s less tedious to move than let-s?

05:06 <discocaml> <sim642> I think it's the other way around because let-s are uniform whereas let rec-s have and-s for non-first bindings

07:53 <discocaml> <octachron> With massive let-rec group, you are also likely to run into generalization issues (because functions are monomorphic until the end of their definition).

13:21 <theblatte> is there a way to make memtrace (https://github.com/janestreet/memtrace) gather statistics on several OCaml processes at once in the same invocation? infer forks worker processes and the only thing I've managed to do is dump a profile for a single one of them (which is probably good enough, but curious if there's something obvious I'm missing)

17:26 <zozozo> theblatte: I think you can control the file where the memtrace info is dumped, so at least you should be able to trace all of your processed separately

19:38 <discocaml> <akhilindurti> with let-recs, you don't have to move anything. my code can stay where it is, but if i introduce calls to a function, i don't have to re-sort them manually in dependency order

19:38 <discocaml> <akhilindurti> true, this is a downside

22:47 <discocaml> <barconstruction> In a mathematics textbook, everything could be perfectly well-defined regardless of the order of the definitions but almost always, mathematics textbooks are organized in order of dependency. Rarely, for an extremely complicated definition or theorem, one might blackbox the definition or theorem in order to use its results up front and then give the proof or definition later, but it would be quite difficult to read.

22:47 <discocaml> <barconstruction> Perhaps what we are missing is that you have some perfectly reasonable organizational style which conflicts with dependency order and you are not just inserting your definitions in a completely random and haphazard order. If so you should explain and it would help us to understand.

22:47 <discocaml> <barconstruction> Otherwise, imo it would substantially improve the readability of the code if you organized things in order.

22:47 <discocaml> <barconstruction> Moreover it would help to avoid accidental / unintentional cyclic dependencies.

22:47 <discocaml> <barconstruction> To me, definitions not in order of dependency is like starting to build a house at the top and then working your way down, putting bricks in mid air and inserting them casually.

22:54 <discocaml> <barconstruction> I also don't follow your argument about refactoring. To me the only time refactoring would force you to do this is if `f` originally depended on `g` but you wanted to refactor so that `g` depended on `f`. This seems like a fairly infrequent refactor, because it would be refactoring not just organization but the basic causal logic of the program

22:56 <discocaml> <akhilindurti> > imo it would substantially improve the readability of the code

22:56 <discocaml> <akhilindurti> I don't dispute this. and once i end up publishing this code for people to read, i'll probably re-partition all these `let-rec` definitions and sort them in dependency order (which is why i asked my original question if there was a tool to help me do that).

22:56 <discocaml> <akhilindurti> But during development, it interrupts my prototyping/iteration if every time a function defined above suddenly needs to depend on one defined below, i have to move things around (and it happens quite a lot from my experience).

22:56 <discocaml> <barconstruction> 👍

23:17 <src> I just had a simple btree in OCaml and on a whim thought "how would I implement this in C++"

23:18 <src> I'm still largely stupid when it comes to programming and in no way a master of C++, but partly it sure as hell seems OCaml is brilliantly elegant regarding certain data structures and operations, especially "self-referencing ones" while w/ C/C++ you end up with... A MESS