01:21 <discocaml> <chrisarmstrong> I was wondering about the ml file generation and how taxing that might be on the compiler:

01:21 <discocaml> <chrisarmstrong>

01:21 <discocaml> <chrisarmstrong> * the code is split up into one module per type (and there can be hundreds of types for just one service e.g. EC2)

01:21 <discocaml> <chrisarmstrong> * serialiser/deserialisers are generated for each AWS protocol type (awsjson, awsquery, etc) even though each service typically only uses one

01:25 <discocaml> <chrisarmstrong> I was thinking about the ml file generation and how taxing that might be on the compiler:

01:25 <discocaml> <chrisarmstrong>

01:25 <discocaml> <chrisarmstrong> * the code is split up into one module per type (and there can be hundreds of types for just one service e.g. EC2)

01:25 <discocaml> <chrisarmstrong> * serialiser/deserialisers are generated for each AWS protocol type (awsjson, awsquery, etc) even though each service typically only uses one

01:25 <discocaml> <chrisarmstrong> * sexp deriving is added to all the main types (with ocaml-cfgen i found it was better to just generate the code for them for json serialisation instead of a ppx)

12:05 <discocaml> <Et7f3 (@me on reply)> Have you explored using option (like ocaml compiler: flambda, ...) to enable various libraries.

12:07 <discocaml> <Et7f3 (@me on reply)> https://opam.ocaml.org/packages/ocaml-option-bytecode-only/

12:19 <discocaml> <agarwal1975> Perhaps the main thing is to generate each submodule into its own ml. We are currently putting all the code for each service in one giant values.ml file. That is because the submodules are mutually recursive sometimes. However, that is rare. We should be able to workaround that and avoid the giant Values module. That would also improve the API by removing the extraneous Values name.

12:22 <discocaml> <agarwal1975> We tried flambda a little, but didn't evaluate its effects rigorously. We ddin

12:22 <discocaml> <agarwal1975> We tried flambda a little to compile awsm, but didn't evaluate its effects rigorously. We haven't tried customizing the installation of ocaml itself.

12:23 <discocaml> <agarwal1975> We tried flambda to compile awsm, but didn't evaluate its effects rigorously. We haven't tried customizing the installation of ocaml itself.

12:24 <discocaml> <chrisarmstrong> Yes the mutually recursive types in a number of AWS sdks are quite annoying and in my experience make it hard to split up, but it is doable I think.

12:27 <discocaml> <Et7f3 (@me on reply)> Ah no I proposed to use the same mechanism. Here you have a base package with compiler configured in a certain ways. And installation of these fake package modify the component installed. This way you have one package with all findlib meta (but you enable only what you need)

12:29 <discocaml> <Et7f3 (@me on reply)> It might reduce maintenance burden because you have to do one PR to update the SDK. and you can expose only a subset of library (with the option)

12:30 <discocaml> <agarwal1975> Oh, so you mean about how to manage a release to opam? I'm not getting it. Are you saying we could release only one opam package?

12:33 <discocaml> <Et7f3 (@me on reply)> Yes

12:34 <discocaml> <Et7f3 (@me on reply)> https://github.com/ocaml/opam-repository/blob/0f0319b6fdf6c811c00ecf56bb035dc471f21090/packages/ocaml-variants/ocaml-variants.5.1.0~beta1%2Boptions/opam#L32-L55

12:34 <discocaml> <Et7f3 (@me on reply)> here is where the logic is done. It is the same package: ocaml-variant

12:34 <discocaml> <Et7f3 (@me on reply)>

12:34 <discocaml> <Et7f3 (@me on reply)> This package change when other package are present like the various options-ocaml

12:35 <discocaml> <Et7f3 (@me on reply)> https://github.com/ocaml/opam-repository/blob/0f0319b6fdf6c811c00ecf56bb035dc471f21090/packages/ocaml-variants/ocaml-variants.5.1.0~beta1%2Boptions/opam#L32-L55

12:35 <discocaml> <Et7f3 (@me on reply)> here is where the logic is done. It is the same package: ocaml-variant

12:35 <discocaml> <Et7f3 (@me on reply)>

12:35 <discocaml> <Et7f3 (@me on reply)> This package change when other package are present like the various ocaml-options

12:36 <discocaml> <agarwal1975> Got it. Okay, we'll look into this. I'm not sure of the details and what the result on the end user experience is.

12:38 <discocaml> <agarwal1975> FYI, we have a lot of other work to do also. We aim to simplify the usage of different concurrency models. It is still a bit too hardcoded, and we think we can generalize it further.

12:41 <discocaml> <Et7f3 (@me on reply)> publishing multiple independent package is better for end-users (because it avoid recompiling each libs) but is more complex for maintainers (you have to open multiple PR when a bump happen)

12:41 <discocaml> <Et7f3 (@me on reply)>

12:41 <discocaml> <Et7f3 (@me on reply)> Using options on the other hand make it easier to package for you (when a bump happen just publish one package) user might need to recompile it when an option is added. If they have a dune cache it is mostly no-op.

12:41 <discocaml> <Et7f3 (@me on reply)>

12:41 <discocaml> <Et7f3 (@me on reply)> It is fine, I just saw it is one tasks you need to do and I proposed a solution.

12:42 <discocaml> <Et7f3 (@me on reply)> (you can ping me for help with packaging)

12:43 <discocaml> <agarwal1975> Thank you for the suggestion. I'm generally inclined to prioritize end users, but that often means it takes us longer to get things done. 🙂

13:15 <discocaml> <xavierm02_> Let's say I have a module `Int : sig type t = int (* and a lot of stuff *) end`, and I want to define `Nat : sig type t = private int let of_int_exn : int -> t (* and the same stuff *) end`. This can be done with `module Nat = struct type t = private int let of_int_exn i = assert(i >=0); i include (Int : S) end` with `S = module type of Int with t := private int`, except that this `t := private int` substitution does not work, so

13:22 <discocaml> <._null._> Imagine you have `module Int = struct type t = int let a : t = -1 end` how would you "interpret" this module in `Nat` ?

13:40 <discocaml> <xavierm02_> I would shadow it after the include

13:41 <discocaml> <xavierm02_> Well for functions, e.g. substract, I would shadow them and add asserts. For a `-1` constant, I'd probably want to remove it, but there isn't one in my use case

13:42 <discocaml> <xavierm02_> The "right" way of doing things would be to have an operation that takes a signature and a set of names, and returns the signature restricted to the set of names, but I don't think that exists, so I'm looking for a workaround.

13:55 <discocaml> <octachron> `module Nat : sig type t = private int ... end = Int` is enough.

14:01 <discocaml> <xavierm02_> A priori, I would need `struct include Int let of_int_exn i = assert(i >=0); i end` in place of `Int`. And I still have to write the `...` which is fairly big.

14:13 <discocaml> <octachron> That's the stable solution. Using `module type of` makes your definition brittle since an update to `Stdlib.Int` may break it.

17:56 <discocaml> <vphantom> I dared upgrade from ocamlformat 0.20 to 0.26 and I'm fighting to try to get what I'm looking for. I got it generally okay except for two very specific annoyances which I can't find mentioned in their GitHub issues or the help page. Do I ask for help in a channel here, the forums or open a ticket which may just be educational?

17:57 <discocaml> <vphantom> I dared upgrade from ocamlformat 0.20 to 0.26 and I'm fighting to try to get what I'm looking for. I got it generally okay except for two very specific annoyances which I can't find mentioned in their GitHub issues or the help page. Do I ask for help in a channel here, the forums or open ~~a ticket~~ an issue which may just be educational?

18:35 <discocaml> <kakadu18> @vphantom you wouldn't know until you try it...

19:27 <discocaml> <vphantom> My question was which of those 3 venues is most appropriate for this kind of question.

19:27 <discocaml> <vphantom> My question was: which of those 3 venues is most appropriate for this kind of question?

19:28 <discocaml> <vphantom> Not the point. 😉 My question was: which of those 3 venues is most appropriate for this kind of question?

19:29 <discocaml> <anmonteiro> Using options is also opam-only and doesn’t take into account that other package managers also support OCaml libraries

21:09 <discocaml> <Et7f3 (@me on reply)> In nix with already have the withSomething pattern. I think esy lack support for installed variable (and default to true)

21:09 <discocaml> <Et7f3 (@me on reply)> Any other package managers I forgot ?

21:17 <discocaml> <anmonteiro> off the top of my head?

21:17 <discocaml> <anmonteiro> - debian https://packages.debian.org/stable/ocaml/

21:17 <discocaml> <anmonteiro> - archlinux https://archlinux.org/packages/extra/x86_64/ocaml/

21:28 <discocaml> <Et7f3 (@me on reply)> It doesn't make sense for system packager because they will enable the minimum so all revdeps works.

21:29 <discocaml> <anmonteiro> exactly. to maximize the number of available libraries, they should be independent (no option-mucking)