01:24 <discocaml> <hockletock> looks like `assert%lwt` in place of `assert` and `[%lwt raise e]` instead of `raise e`

02:51 <dh`> that's not compositional and won't work in my context

02:57 <companion_cube> Hopefully we all move to eio or similar soon, so that this may not be an issue anymore

03:00 <dh`> on another topic, my first request for trying to write non-compiler code in ocaml would be: syntactic sugar for returning a value early from a function

03:02 <discocaml> <hockletock> isn't that an Effect use case?

03:02 <dh`> maybe but that sounds far more elaborate than necessary

03:02 <dh`> it's just syntax

03:02 <discocaml> <hockletock> you mean like "return x"?

03:03 <dh`> yes

03:05 <dh`> let f = match a with | B -> return c | D -> e in g becomes match a with | B -> c | D -> let f = e in g, modulo variable capture silliness

03:05 <dh`> and you want a slightly more advanced substitution to avoid duplicating code wildly but it still isn't hard

03:09 <dh`> in particular, let f' = match a with B -> Now c | D -> Continue e in match f' with Now c -> c | Continue e -> let f = e in g

05:18 <companion_cube> dh`: oh I wish

05:38 <dh`> yeah

05:38 <dh`> like, _the_ worst thing is how checking errors at every step increases the indent

11:17 <reynir> if I have a .mli with: type t module Foo : sig type t val t_of_outer_t : t -> t end

11:18 <reynir> ^ so I want to refer to the outer type t but it is shadowed. What's a nice way to go about this?

11:18 <reynir> I know I can define in module Foo a type outer_t = t before defining type t

11:27 <reynir> ok I went with type t module T : sig type nonrec t = t end module Foo : sig type t val t_of_outer_t : T.t -> t end

12:32 <discocaml> <leviroth> You can also do `sig type outer := t` which lets you use `outer` as an alias in your signature without actually exposing the alias for users of the module. See https://v2.ocaml.org/manual/signaturesubstitution.html#ss%3Adestructive-substitution

22:41 <xenu> /w 3

23:02 <darchitect> is there anyone here who experimented with Gemini for generating implementations for type signatures + comments?

23:03 <darchitect> I tried with bard and it's not that great yet

23:12 <discocaml> <Kali> whatever gemini model they're using for bard now is barely any better than whatever bard used to be

23:13 <discocaml> <Kali> i tried it out and it just spits out nonsense and syntax error after syntax error

23:14 <discocaml> <Kali> if the biggest gemini model is as good as google claims, then maybe there's some potential in the future, but it's not accessible yet and what we have now cannot even do intermediate coding tasks with significant user help

23:17 <discocaml> <Kali> in short, it's not ready yet, and may not ever be ready

23:18 <discocaml> <Kali> google has been consistently putting out low-quality llms with promises of it getting better on some arbitrary benchmarks when they're still basically just as faulty for actual use cases as before

23:20 <discocaml> <Kali> particularly egregious were the new videos showcasing gemini's capabilities (which was extremely edited and misleading in the impressive cases, and almost hilariously bad in the others)

23:20 <discocaml> <Kali> i digress; this channel is for ocaml