02:18 <discocaml> <loves_curry> this is more of a general question: is it possible to make useful, complex programs in OCaml without using any imperative features?

02:18 <discocaml> <loves_curry> i.e mutable variables, normal loops etc

02:23 <discocaml> <Kali> just as much as it is in haskell

02:24 <discocaml> <Kali> there are plenty of ocaml programs which utilize no imperative features

02:24 <discocaml> <Kali> understand that it is not really recommended to use imperative features except for parts where you want speed guarantees

02:25 <discocaml> <Kali> and the syntax is a little ugly too, not very readable compared to the equivalent functional program

02:26 <discocaml> <Kali> all the `:=`s and `!`s and `<-`s and `;`s become visually dirty after a bit

02:29 <discocaml> <loves_curry> cool thanks!

02:30 <discocaml> <loves_curry> also, OCaml lists are internally linked lists right? do they have the same cache locality issues inherent to linked lists in general or is there something specific about the implementation to avoid this?

02:31 <discocaml> <Kali> yes, they are linked lists just as in haskell

02:31 <discocaml> <Kali> however, ocaml has a native array type

02:31 <discocaml> <Kali> if you wish to use that instead

02:32 <discocaml> <Kali> the syntax is practically identical

02:32 <discocaml> <Kali> [| |] instead of [ ]

02:33 <discocaml> <Kali> to access, you do `array.(n)`

02:33 <discocaml> <Kali> to set, `array.(n) <- n'`

02:34 <discocaml> <Kali> there are also mutable lists provided as `'a Seq.t`

02:34 <discocaml> <Kali> or, rather, single-use lists

02:35 <discocaml> <Kali> additionally, seqs are lazy

02:35 <discocaml> <Kali> they are modified in-place

02:36 <discocaml> <Kali> to avoid duplication

02:41 <discocaml> <contificate> They can have issues, but most cases the lists are small enough that it doesn't really matter. Lots of patterns tend to result in cons cells being local to each other on the minor heap, so they're commonly as distant as you might think (or could achieve with a poor implementation of `malloc` and linked lists in C). I can't speak to the layout of OCaml's major heap, but, in simpler schemes, it's an explicit goal to try and improve locality

02:42 <discocaml> <contificate> As mentioned, there's pretty idiomatic altenatives to cons lists if you need them.

02:42 <discocaml> <contificate> As mentioned, there's pretty idiomatic alternatives to cons lists if you need them.

02:44 <discocaml> <contificate> They can have issues, but most cases the lists are small enough that it doesn't really matter. Lots of patterns tend to result in cons cells being local to each other on the minor heap, so they're commonly not as distant as you might think (or could achieve with a poor implementation of `malloc` and linked lists in C). I can't speak to the layout of OCaml's major heap, but, in simpler schemes, it's an explicit goal to try and improve local

18:15 <discocaml> <kakadu18> Folks, does opam resolve dependencies very slow on your machines too? https://gist.github.com/Kakadu/7eb873118ba9fec92bc568fdcce16e2b#file-log-txt-L20 I observed how it takes 8 seconds to check that no dependecies of ppx_compare should be installed. It looks like very slow...

19:04 <Anarchos> kakadu18 opam update takes more than 40min for me...

19:11 <discocaml> <kakadu18> 40 minutes is too much. The --debug switch may explain what is going on....

19:19 <Anarchos> kakadu18 it is the tar/untar of the repo which is really long

19:32 <discocaml> <kakadu18> I heard rumors about this in the curcumstances where people untarring on NTFS drive connected to WSL2... But very likely it is not your case...

19:36 <Anarchos> kakadu18 it is a spinning hard drive on a OLPC laptop...

19:42 <discocaml> <kakadu18> poor children TT

19:52 <Anarchos> kakadu18 indeed

19:52 <Anarchos> kakadu18 i will try with --debug next time