00:43 <discocaml> <xavierm02_> I've been using https://github.com/tweag/opam-nix

00:43 <discocaml> <xavierm02_> It works really well

01:15 <discocaml> <ape_logic> I use nix-overlays, I couldn't really grok how opam-nix works

01:15 <discocaml> <ape_logic> I use the nix-ocaml one, I couldn't really grok how opam-nix works

01:16 <discocaml> <ape_logic> maybe I should try it again now I understand OCaml more

01:17 <discocaml> <ape_logic> oh, it looks like it doesn't have any substituters.. so that's a big +1 to nix-ocaml, they're all precompiled

02:02 <discocaml> <darrenldl> anyone using sqlite3 or caqti package? wondering about quality, ease of use etc

02:06 <companion_cube> sqlite3 is excellent but it's low level bindings

02:29 <discocaml> <yawaramin> various OCamlers have their favourite wrappers for it, i have one called fun-sql

02:38 <companion_cube> I have one called sqlite3_utils :)

09:32 <discocaml> <xavierm02_> ddddd: I don't really understand it either, but pasting the flake.nix (and changing the package name in it) in a project that has an opam file is enough to get a working `nix develop` (unless there are native dependencies, but even then you just need to list them at the right place in the flake.nix), which I find pretty convenient

09:34 <discocaml> <xavierm02_> With nic-ovaml/nix-overlays, you have to explicitly list all dependencies in the flake.nix, don't you?

10:04 <discocaml> <ape_logic> yup, they are overlaid into pkgs.ocaml-ng

12:29 <discocaml> <xavierm02_> Is there some way to automatically erase fields of type unit, i.e. have `Obj.size (Obj.repr {a = 1; b = ()})` be `1` instead of `2`?

12:30 <discocaml> <octachron> No that would be unsound.

12:31 <discocaml> <octachron> You don't want to have a crash for `type 'a t = { a: int; b:'a } let b r = r.b let () = b { a=0; b = () }`.

13:00 <discocaml> <xavierm02_> octachron: I forgot to specify the type but I meant `type t = { a: int; b: unit }`, and I think it'd be sound to replace all `r.b` (where `r : t`) by `let _ = r in ()`.

13:03 <discocaml> <octachron> Then you are probably generating the type, and you can automatically not generate the field.

13:07 <discocaml> <xavierm02_> Hm. In my use case they'd be generated by a functor. Where can I find information on the runtime representation of functors?

13:08 <discocaml> <octachron> There is also the issue that this still unsound with respect to type abstraction: `M:sig type t type r = { x: t; y:t } end = struct type t = unit ... end`.

13:09 <discocaml> <octachron> Functors are just functions at runtime.

13:09 <discocaml> <xavierm02_> Polymorphic functions, so they run into your previous crash example?

13:10 <discocaml> <octachron> And changing the shape of type depending on functor argument would be unsound.

13:10 <discocaml> <octachron> There is no types at runtime.

13:13 <discocaml> <xavierm02_> Yes, I mean that all instances use the same generated code like for polymorphic functions, as opposed to if you monomorphise and duplicate the code for each instance

13:17 <discocaml> <xavierm02_> Anyway, I got the answer to my initial question: not currently possible. Thanks!

16:27 <companion_cube> Bytesrw seems promising

19:27 <discocaml> <mbacarella> so, what's the legacy of lightweight higher-kinded polymorphism? yallop and white freed us from the tyranny of functors but it seems like it wasn't really taken up?

19:27 <discocaml> <mbacarella> seems like... people actually alike functors?

19:27 <discocaml> <mbacarella> seems like... people actually like functors?

19:29 <discocaml> <octachron> The lightweight higher-kinded article presents a hack that is not supposed to be used in practical settings.

19:30 <discocaml> <octachron> The non-hackish version is modular explicit/path dependent function/lightweight functor which has a review in progress.

19:30 <discocaml> <octachron> https://github.com/ocaml/ocaml/pull/13275

19:32 <discocaml> <mbacarella> @octachron hmm. interesting.

21:33 <discocaml> <hannes6838> that's a bit too general... from my perspective there are some OCaml developers who're very keen on functors... and 90% who are not... I personally try to remove functors when I see them

21:39 <discocaml> <barconstruction> "That claim is a bit too general" (immediately makes a bold sweeping claim in the opposite direction)

21:42 <companion_cube> I'd agree, I mostly avoid functors

21:44 <discocaml> <barconstruction> "90% of OCaml programmers dislike the feature that most distinguishes the language from every other major programming language." is plausible but it raises follow up questions. Sounds a bit like "90% of Go developers dislike goroutines" - why are you using Go?

21:50 <dh`> I don't think it's reasonable to claim that ocaml is so much more major than sml that sml can be ignored

21:53 <discocaml> <hannes6838> you're right, that claim of 90% was not very wise. thanks for your comment.

21:54 <dh`> also, asking whether coq is major will probably just start an argument but it does also have functors

21:54 <discocaml> <hannes6838> and there are various fine uses of functors where I'm happy OCaml has them 😄

21:58 <discocaml> <mbacarella> I consider myself a functor enjoyer

22:03 <dh`> functors have definite value when writing something highly virtualized/parameterized, but it's extremely annoying to need to lay down functors every time you need an abstract type

22:17 <discocaml> <._null._> dh`: Coq's functors are very rarely used as far as I'm aware, and very badly understood as per the people who implemented them

22:19 <dh`> maybe so but they're all over the stdlib

22:40 <discocaml> <ape_logic> is a functor basically a thing that generates a module by filling in some abstract types to concrete?

22:40 <discocaml> <ape_logic> is a functor basically a thing that generates a module by filling in some abstract types in another module to concrete?

22:53 <Anarchos> ape_logic it takes a module and returns a module.

23:00 <discocaml> <ape_logic> right so a parameterised module

23:01 <discocaml> <ape_logic> oh wait it TAKES a module too

23:01 <discocaml> <ape_logic> hmm

23:27 <discocaml> <Kali> a functor is a module level function, essentially