00:45 <discocaml> <gubsey> Does anyone know why ocaml doesn't have list comprehension? Being so similar to Haskell it's an interesting omission. I'm okay with it not being there, and I can think of plenty of reasons on my own, but I'd love to know the actual reason.

00:45 <discocaml> <gubsey> I much prefer the list tools we have btw.

00:48 <discocaml> <Kali> it doesn't have specific syntax for list comprehension, but list comprehension is just `map`; you could use a let-op if you wanted to make it special:

00:48 <discocaml> <Kali> ```ocaml

00:49 <discocaml> <Kali> let ( let+ ) = List.map

00:49 <discocaml> <Kali>

00:49 <discocaml> <Kali> let () = List.iter print_int (let+ x = [1;2;3;4;5] in x + 2)

00:49 <discocaml> <Kali> (* 34567 *)

00:49 <discocaml> <Kali> ```

00:49 <discocaml> <._null._> You can get some equivalent with monadic lets, e.g. `let* i = List.init 10 Fun.id in let* j = List.init 5 ((+) 100) in [i+1; i*j]`. If you also give yourself nice operators for simple lists, you get something

00:50 <discocaml> <Kali> it doesn't have specific syntax for list comprehension, but list comprehension is just `map` or `concat_map` depending on the context; you could use a let-op if you wanted to make it special:

00:50 <discocaml> <Kali> ```ocaml

00:50 <discocaml> <Kali> let ( let+ ) = List.map

00:50 <discocaml> <Kali>

00:50 <discocaml> <Kali> let () = List.iter print_int (let+ x = [1;2;3;4;5] in x + 2)

00:50 <discocaml> <Kali> (* 34567 *)

00:50 <discocaml> <Kali> ```

00:51 <discocaml> <Kali> *oops, i meant `let ( let+ ) l f = List.map f l`

00:53 <discocaml> <Kali> and `let ( let* ) l f = List.concat_map f l`, respectively

00:59 <discocaml> <Kali> you can also do some stuff with the custom indexing operators, like this:

00:59 <discocaml> <Kali> ```ocaml

00:59 <discocaml> <Kali> let ( .>() ) l f = List.map f l

00:59 <discocaml> <Kali> let ( .!() ) l f = List.iter f l

00:59 <discocaml> <Kali>

00:59 <discocaml> <Kali> let () = [1;2;3;4;5].>(fun x -> x + 2).!(print_int)

00:59 <discocaml> <Kali> ```

00:59 <discocaml> <Kali> (the indexing operators don't have standard operator names associated with them like let-ops for applicatives (`+`)and monads (`*`) do as far as i know, so take my choice of indexing operator with a grain of salt)

01:02 <discocaml> <geoff> oh god, I never thought of that use of indexing operators 😂

01:03 <discocaml> <Kali> 😂 yeah, i would certainly not recommend doing this, it's not exactly the most readable

01:03 <discocaml> <Kali> it looks kinda cool though...

01:07 <discocaml> <Kali> i once gave all the common list functions their own indexing operation just for fun:

01:07 <discocaml> <Kali> https://cdn.discordapp.com/attachments/436568060288172044/1137552415315460106/Screenshot_20230805_210531.png

01:07 <discocaml> <Kali> this is a very silly way to program, but it's good for laughs

01:35 <discocaml> <vphantom> Kind of reminds me of Brainf*ck.

09:00 <discocaml> <froyo> no that looks like something someone who writes apl-family langs would do lol

11:07 <tom1212> Hello! concerning "recursive" modules: got a functor UniPoly (R: Ring) -> sig include Ring module BaseRing = R end for univariate polys, I can define UniPoly(UniPoly(Integers)) for bivariate polys Z[X][Y]

11:07 <tom1212> but if you do UniPoly(UniPoly(Integers)).BaseRing you get a Ring and loose the fact that it is actually a poly

11:08 <tom1212> is there a way to keep the info that BaseRing is actually a poly in this case?

11:10 <tom1212> I'd like to define NVariatePoly (R: Ring) (sig val arity:int end) -> sig include Ring module BaseRing = R val arity: int end and do write a function to assert that NVariatePoly(Z)(struct let arity=2 end)=UniPoly(UniPoly(Integers)) and for that I need to introspect the base ring

11:31 <tom1212> brb, can check out the logs

13:29 <discocaml> <yugamii> si there any documentation on using cohttp-eio?

13:30 <discocaml> <yugamii> si there any documentation on using cohttp-eio client?

23:25 <discocaml> <rbjorklin> https://ocaml.org/p/cohttp-eio/latest/doc/Cohttp_eio/Client/index.html