06:41 <discocaml> <doraent> This is what I think aswell, but basically everytime we need to enforce the type of something we can use a .mli file/something lighter than a module type. It really looks like a java version translated to ocaml

06:42 <discocaml> <doraent> Sadly the maintainer does not answer any issue anymore, in fact the repo of the ocaml-version is dead (the book cannot even be built from there)

09:15 <discocaml> <octachron> From my memory, the main issue is that some of the later examples need higher-kinded polymorphism, which need to go through functor in OCaml. And thus the OCaml version of the book decided to use functors even for basic function composition.

10:41 <discocaml> <doraent> yes but this is not only a choice, this is strictly speaking an error at some points. A good example is the very first snippet :

10:41 <discocaml> <doraent> ```ocaml

10:41 <discocaml> <doraent> module Compose_Example

10:41 <discocaml> <doraent> (F : Polymorphic_Function_F)

10:41 <discocaml> <doraent> (G : Polymorphic_Function_G with type b = F.b) =

10:41 <discocaml> <doraent> struct

10:41 <discocaml> <doraent> (** OCaml doesn't have a compose operator. So, creating one. **)

10:41 <discocaml> <doraent> let ( >> ) g f x = g (f x)

10:41 <discocaml> <doraent> let compose : 'a -> 'c = G.g >> F.f

10:42 <discocaml> <doraent> end

10:42 <discocaml> <doraent> ```

10:42 <discocaml> <doraent> here there is no need to declare 2 module types for F and G, and it does not even fit the idea of the haskell snippet.

10:46 <discocaml> <doraent> Moreover, some parts of the book are basically haskell-focused (not only the snippets), A very easy example is the string types in Ocaml/Haskell, in Haskell String = [Char] which is not true at all in Ocaml. I am pretty sure we can find tons of other examples (i found some in the parts about recursion, which is not handled exactly in the same way in ocaml and haskell)

10:59 <discocaml> <otini_> maybe it was translated from Haskell by someone who didn’t know or didn’t care about ocaml’s specificities?

11:03 <discocaml> <doraent> I am pretty sure it is the case, yes (and I think the objective of this "translation" was only to give ocaml snippets, and not fully express the book idea in ocaml)

17:52 <discocaml> <yawaramin> agree. i made an attempt but it's a big task https://github.com/hmemcpy/milewski-ctfp-pdf/pull/242

18:03 <discocaml> <alyxshang> Chat can I have a hug

18:04 <discocaml> <alyxshang> I finally understood pointers

18:04 <discocaml> <alyxshang> I'm so happy I could cry

18:04 <discocaml> <._null._> Thanks to OCaml ?

18:04 <discocaml> <alyxshang> No, Ed from low-level-learniny and my old code.

18:04 <discocaml> <alyxshang> No, Ed from low-level-learning and my old code.

18:05 <discocaml> <alyxshang> I'm trying to keep the positive-feedback loop going.

18:05 <discocaml> <alyxshang> For learning things about my field I have missed.

18:05 <discocaml> <alyxshang> (That includes OCaml)

18:06 <discocaml> <._null._> Makes more sense, but good for you. As someone who forgot why pointers are difficult, what did you not understand ?

18:08 <discocaml> <alyxshang> I got confused between assigning a pointer to a mem location and dereferencing said pointer later on. The double use of the asterisk for either task.

18:08 <discocaml> <alyxshang> But I got it now.

18:08 <discocaml> <alyxshang> And that the "&" is a reference to the mem location of the created variable.

18:10 <discocaml> <._null._> That *p behaves similarly to p[0] for arrays so ? Where you both get and set them using the "same" syntax ?

18:23 <discocaml> <lukstafi> `[@@deriving sexp_of]` feature wish: in addition to `@opaque`, have a way to provide an alternative sexper... My workaround for a specific use case -- to break up sexping a recursive record, duplicate the record definition and in the second one use `[@@deriving sexp_of]`, for the first one manually write the sexper to output the record id.

18:25 <discocaml> <alyxshang> Well yes, but imagine how cryptic this was for a crab when it first had some C code between its pincers.

18:28 <discocaml> <._null._> I'm much less used to the situation in Rust, but I at least know that it's quite different

18:52 <dh`> rust reference syntax is very confusing

18:55 <companion_cube> it's just & and * though?

18:57 <discocaml> <cristianoc> Not sure how relevant to this discussion, just adding some detail.

18:57 <discocaml> <cristianoc> In ReScript, currying in application is optional instead of the default. Making partial application opt-in.

18:57 <discocaml> <cristianoc> Plus, higher-order functions are explicit about the arity, which is a real change, though in practice the difference comes up less often than one would expect.

18:57 <discocaml> <cristianoc> (The motivation there is when interfacing with JavaScript directly one has to pay the price for the mismatch between ambiguous arity on one side and explicit arity on the other side).

18:58 <discocaml> <doraent> Basically we should do this everywhere, and even adapt the text to make it a real "ocaml version" and not juste ocaml snippets with some Haskell text

19:00 <dh`> cube: rust? yes, except where it's not, and it's subtly different in places, and there are implicit conversions

19:03 <companion_cube> I'd love to hear more, to me it's fairly straightforward

19:03 <companion_cube> only place it's tricky is in patterns, and even then

19:04 <dh`> I have not used it that much yet and it may just be that the intro documentation is obfuscating it

19:06 <dh`> but there are definitely implicit conversions from scalar values to references to them

19:06 <dh`> which C specifically doesn't allow

19:09 <companion_cube> nope, never

19:09 <companion_cube> all references in rust are explicit

19:09 <companion_cube> a few _de_references are implicit in cases where it's obvious

19:12 <dh`> ok, maybe I'm confused

19:12 <dh`> implicit dereferences are just as bad though

19:13 <companion_cube> having foo.x deference when foo is a reference sounds fine to me

19:13 <companion_cube> you don't gain much by disallowing that

19:17 <dh`> other than keeping a strict separation of concepts

19:18 <dh`> this is why C has ->

19:19 <companion_cube> it's just useless to separate the two in this case

19:24 <discocaml> <astreamingcomesacrossthesky> What are the optics on using archived libs in the OCaml-sphere? I wanna check out Bastet. Is it archived bc there's something wrong with it? Or is it merely stable and useable?

19:32 <discocaml> <deepspacejohn> (I assume you mean the "archived" status on the GitHub repo) I don't think archiving has any implicit meaning in the OCaml ecosystem. I'm not sure about Bastet specifically.

19:37 <discocaml> <astreamingcomesacrossthesky> Right, yeah, I do mean on GH. Good to know, thanks. I found it from a cursory search into category theory libraries but if there are others I'm glad to take recommendations. I know Base has cats stuff but I'm not sure I wanna bring in all that just for a small part of the whole.

19:49 <discocaml> <alyxshang> Yeah, in Rust you just have an ampersand for refs and an asterisk for dereferencing things.

19:49 <discocaml> <alyxshang> Provided certain traits are implemented for the latter.

19:55 <companion_cube> no new language is keeping -> as a dereference operator, fwiw

19:56 <companion_cube> auto deref on field or method access is just the norm now

20:35 <Anarchos> ir

20:35 <Anarchos> bonsoir

20:59 <dh`> right, in C you just have ampersand and star, but it's somehow not the same in a bunch of corners

21:00 <dh`> (besides the declaration syntax, where the C declaration syntax is awful)

21:04 <companion_cube> and -> like you said

21:14 <dh`> -> is purely syntactic though

21:42 <discocaml> <diligentclerk> I downloaded the Jane Street extensions and it's slower than my original code and I don't know why lmao

21:55 <discocaml> <diligentclerk> ```ocaml

21:55 <discocaml> <diligentclerk> let pi_approx : int -> float = fun n ->

21:55 <discocaml> <diligentclerk> let rec pi_sum k acc=

21:55 <discocaml> <diligentclerk> (if k = 0 then acc else pi_sum (k-1)

21:55 <discocaml> <diligentclerk> (acc +. 1./. (let a = float_of_int k in a *. a))) in

21:55 <discocaml> <diligentclerk> Float.sqrt @@ (6. *. pi_sum n 0.)

21:55 <discocaml> <diligentclerk> ;;

21:55 <discocaml> <diligentclerk>

21:55 <discocaml> <diligentclerk> let pi_approx_while n =

21:55 <discocaml> <diligentclerk> let acc = ref 0. in

21:55 <discocaml> <diligentclerk> let k = ref n in

21:55 <discocaml> <diligentclerk> while !k != 0 do

21:55 <discocaml> <diligentclerk> acc := !acc +. 1./. (let a = float_of_int !k in a *. a);

21:55 <discocaml> <diligentclerk> k := !k - 1

21:55 <discocaml> <diligentclerk> done;

21:55 <discocaml> <diligentclerk> Float.sqrt @@ 6. *. !acc

21:55 <discocaml> <diligentclerk> ```

21:55 <discocaml> <diligentclerk> With the Jane Street compiler, `pi_approx 1_000_000` is 50% slower and `pi_approx_while 1_000_000` is 100%-120% slower.

22:10 <discocaml> <Kali> avoid pasting code blocks in this channel

22:11 <discocaml> <Kali> each newline has to be sent as a separate message for the irc bridge

22:12 <dh`> and irc is resistant to that because of a multi-decade history of DoS attempts

22:14 <discocaml> <Kali> instead of "while !k != 0", you should use "while !k <> 0", and you can also use "decr k" for "k := !k - 1"