01:56 <d_bot> <cod1r> hi

04:56 <d_bot> <Ambika E.> Sup

05:42 <d_bot> <cod1r> Sup

07:47 <d_bot> <Patate> Hello, is it possible to split two modules that depend on each other int two separate .ml files?

07:54 <d_bot> <octachron> No, cyclic dependencies are not allowed for compilation units.

07:57 <d_bot> <Patate> Okey, thanks, I just saw you can transform them to functors (taking the module they depend on), and then do something like this to get the modules;

07:57 <d_bot> <Patate> ```ocaml

07:57 <d_bot> <Patate> module rec M1 = F1(M2)

07:57 <d_bot> <Patate> and M2 = F2(M1)

07:57 <d_bot> <Patate> ```

08:00 <d_bot> <Patate> So I guess it is possible to at least put these functors in different files

08:08 <d_bot> <octachron> Functors are indeed a way to break a cyclic dependency. It is also often possible to break the cycle by isolating a (strongly connected) core subset of both modules into their own separate module, since it is rare that everything in `M1` depends on everything in`M2` and reciprocally.

08:41 <d_bot> <Continuation Calculus> (I would also not recommend recursive modules like this except if there is no other way)

09:00 <d_bot> <Patate> Oh? why so?

09:01 <d_bot> <Continuation Calculus> Because I had many different kinds of problems everytime I wanted to expand beyond straightforward stuff

09:01 <d_bot> <octachron> Recursive modules are one of the most complex feature of the language (and no one knows a good specification for them).

09:02 <d_bot> <Continuation Calculus> Yup.

09:02 <d_bot> <Continuation Calculus> And I would add, not "complex" in a "the module system is so complex and powerful with abstraction and functors way!!"-way, but in a "I want to quit everything"-way

09:03 <d_bot> <Patate> urg

09:03 <d_bot> <octachron> Climbing the complexity ladder is something that you should avoid whenever possible (outside of learning experiences). And recursive modules stands very high on this ladder.

09:04 <d_bot> <Continuation Calculus> If you truly must, a minimal recursive module that only contains types, and not build stuff more complex than that on top of it (ie, not a building block in your architecture, but its peak complexity)q

09:05 <d_bot> <Continuation Calculus> If you have an example that you can share, feel free :)

09:05 <d_bot> <Continuation Calculus> There might be a better alternative

09:05 <d_bot> <Patate> So you think I should rather group code in one file? The aim was mostly to split into files for modularity

09:06 <d_bot> <Continuation Calculus> Nope, I more meant that there might be alternatives to have the thing be modukar

09:06 <d_bot> <Patate> Oh I see

09:06 <d_bot> <Continuation Calculus> It's quite rare to truly need mutual dependencies, even if it comes up intuitively

09:11 <d_bot> <Patate> My example is that there is a `Type` module, with a sum `type t`. Each constructor for `t` is like `A of A.t`

09:11 <d_bot> <Patate> Now, in Type, there is `to_string : t -> string`, that can call `A.to_string`. Problem is that `A.t` is made of `Type.t`'s, and so has to call `Type.to_string`

09:11 <d_bot> <Patate> And i wanted a file per constructor so it is modular

09:12 <d_bot> <Patate> some of them do not depend on `Type.t`, so easy, but some of them do...

09:13 <gopiandcode> one alternative would be to make the A.t polymorphic over their recursive occurrences of Type.t

09:14 <gopiandcode> e.g `type t = Example of string * Type.t` --> `type 'a t = Example of string * 'a`

09:17 <d_bot> <Patate> Mmh, that is nice, but what is the equivalent for the functions to_string? as I still need to do :`Example.to_string (s, t) = s ^ (Type.to_string t)`?

09:18 <d_bot> <Patate> Oh I know.

09:19 <d_bot> <Patate> Type.to_string is recursive, and "gives" itsel to Example.to_string.

09:23 <d_bot> <Patate> So `Example.to_string` gets `Type.to_string` as an argument, and uses it on it's E`xample.t` argument's `Type.t` sub-components!

09:24 <d_bot> <Patate> Is that a "more ok" way to go?

09:25 <d_bot> <darrenldl> i think the typical arrangement would be to just put the types in same module? (naming A.t to something else etc)

09:27 <d_bot> <Patate> Yes, but I would like to avoid having everything in the same module, as each constructor of `Type.t` has a different to_string function, and corresponding `type t`

09:28 <gopiandcode> @Patate: yup, exactly

09:28 <d_bot> <darrenldl> you can still use submodules for operations of the different types?

09:28 <d_bot> <darrenldl> (or at least seems relatively usable still, but im not good at api design so hmmm

09:29 <d_bot> <Patate> problem is that operations might depend on the root module Type

09:31 <d_bot> <Patate> Thank you so much @octachron @Continuation Calculus and gopiandcode for discouraging module recursion! This approach indeed looks lot nicer

09:31 <d_bot> <Continuation Calculus> It depends what you mean by "it depends on the root module"

09:32 <d_bot> <Patate> edited

09:33 <d_bot> <Continuation Calculus> Your example of `A.to_string` does not need `Root`. It only needs to be polymorphic and get an auxiliary `to_string` function to use (Same as `List` or `Option`)

09:33 <d_bot> <Continuation Calculus> With pleasure, it will also uncover parts that are more general than expected

09:38 <d_bot> <Patate> what do you mean by "more general than expected"?

09:49 <d_bot> <Patate> what do you mean by "more general than expected" @Continuation Calculus ?

09:49 <d_bot> <Continuation Calculus> Less tied to Root than what you'd expect

09:49 <d_bot> <Patate> Oh, yes, some cases are not tied at all! it's just some of them that pose problem 🙂

16:34 <d_bot> <nlucaroni> It had to have been maybe 3-5 years ago, but someone had posted somewhere about a data structure that was implemented by flipping the polymorphic key value pair at every level. I was thinking about something similar and didn't recall what this original data structure was used to model. I think it was a bimap? Anyway, does anyone have a recollection of what I am thinking about and might know where this post is? I haven't had any

19:24 <d_bot> <mbacarella> ocaml-migrate-parsetree has a `val Versions.migrate : 'from ocaml_version -> 'to_ ocaml_version ('from, 'to_) migration_functions` which doesn't appear to exist in ppxlib?

19:37 <d_bot> <mbacarella> did this get renamed? or is this kind of magic not available anymore?

19:37 <sim642> Doesn't ppxlib migrate to its own internally fixed version of the AST?

19:39 <d_bot> <mbacarella> don't know. just trying to get a project that used to use ppx_tools_versioned to work on recent ocaml

19:41 <d_bot> <mbacarella> this project seems to construct expressions to ast 404 and then migrate them to current to print them.

19:45 <sim642> Looks like ppxlib has astlib in it, which is just some vendored version of OMP

19:47 <d_bot> <mbacarella> right. but OMP includes Versions = Migrate_parsetree_versions whereas astlib does not at all

19:49 <d_bot> <mbacarella> perhaps that's just magic that saves you the trouble of manually bumping from 404 -> 405 -> 406 -> whatever current is

19:50 <d_bot> <mbacarella> oh! it's in ast/versions.ml

19:53 <d_bot> <mbacarella> huh there's a lot of macro stuff here. perhaps this is why my grepping fails. migrate does not appear to be exposed

19:54 <d_bot> <mbacarella> holy crap. objects.

19:55 <d_bot> <mbacarella> i think i need to cancel all of my plans and fly to a hotel room next to the airport in another city and dig the fuck in