00:18 <discocaml> <deepspacejohn> I’ve noticed that seemingly-small changes in a mll file (that still parses the exact same syntax) can make relatively large differences in the compiled output (I’ve noticed just from looking at jsoo output file size). I’m wondering if there are any general guidelines for what things make ocamllex output bigger?

00:18 <discocaml> <._null._> Differences in the ml output you mean ?

00:22 <discocaml> <deepspacejohn> I’m measuring the final compiled output (using jsoo in my case) but yea I assume the ml output size scales relatively linearly with that. So knowing that would be helpful too.

00:24 <discocaml> <._null._> Can you not access the ml intermediate file in the build folder ?

00:33 <discocaml> <deepspacejohn> I can, but I don't know how to inspect which parts of the ml file map to the mll rules/patterns. Perhaps a better question would be: how do you debug the generated `lex_tables` value? It's the part of the code that varies the most.

00:36 <discocaml> <._null._> You can already study the diff, but I cn't help you further

00:36 <discocaml> <._null._> You can already study the diff, but I can't help you further

06:20 <greenbagels> btw companion_cube thanks for the help earlier

06:20 <greenbagels> async may still be slight voodoo to me but slowly but surely I will make sense of it

10:56 <discocaml> <sjver> how does OCaml figure out the parameter count of an external function?

10:56 <discocaml> <sjver> does it just assume that external functions never return functions?

10:56 <discocaml> <sjver> in other words, how does the lowering/codegen phase of the compiler know the arity of an external function?

10:58 <discocaml> <contificate> it knows the type and uncurries it

10:58 <discocaml> <contificate> was my understanding of `external`

10:58 <discocaml> <sjver> so it is assumed that an external function never returns a function?

10:59 <discocaml> <contificate> well, C can return closures to OCaml in the same way C and take closures from OCaml

10:59 <discocaml> <contificate> but I think, for convenience, I _believe_ `external foo : int -> in -> int = "caml_foo"` would expect a C function taking 2 arguments

10:59 <discocaml> <contificate> but I think, for convenience, I _believe_ `external foo : int -> int -> int = "caml_foo"` would expect a C function taking 2 arguments

10:59 <discocaml> <contificate> well, C can return closures to OCaml in the same way C can take closures from OCaml

11:00 <discocaml> <sjver> yes, but how abt `external create_adder : int -> (int -> int)`, which would return a closure?

11:00 <discocaml> <sjver> for example

11:00 <discocaml> <contificate> yes, I believe you can do that

11:00 <discocaml> <sjver> but isn't `int -> int -> int` semantically the same as `int -> (int -> int)`?

11:01 <discocaml> <contificate> yes, but I think there's some implementation detail note about this, for convenience it's not identical

11:01 <discocaml> <contificate> but I may be completely misremembering

11:01 <discocaml> <contificate> could try it and see™️

11:01 <discocaml> <sjver> hmm

11:16 <discocaml> <contificate> nevermind, what I said first appears to be right

11:19 <discocaml> <contificate> > The arity (number of arguments) of a primitive is automatically determined from its OCaml type in the external declaration, by counting the number of function arrows in the type. For instance, seek_in above has arity 2, and the caml_ml_seek_in C function is called with two arguments.

11:19 <discocaml> <contificate> see here: https://v2.ocaml.org/manual/intfc.html

11:23 <discocaml> <sjver> good to know!

11:25 <discocaml> <contificate> confusingly, the manual also notes "Primitives with several arguments are always curried." but I presume this is talking about OCaml's own primitives where they'd never use a tuple to emulate multiple arguments since they probably do some clever stuff for handling C FFI efficiently (but there is a cap on number of arguments to the C back-end iirc)

11:32 <discocaml> <sjver> prob yea

11:32 <discocaml> <sjver> btw, do you happen to know of any documentation of OCaml's execution model?

11:34 <discocaml> <contificate> what do you mean

11:39 <discocaml> <sjver> how it generates code for function application, mainly

11:39 <discocaml> <sjver> idk if it uses eval/apply, push/enter or smth else

11:39 <discocaml> <sjver> but i wanna figure out

11:58 <discocaml> <.armael.> for external functions I think it uses a syntactic criterion

11:59 <discocaml> <.armael.> `external foo : int -> (int -> int) = "caml_foo1"` means that the C function `caml_foo1` will take a single argument and must return a function

11:59 <discocaml> <.armael.> whereas `external foo : int -> int -> int = "caml_foo2"` means that the C function `caml_foo2` will take two arguments and return an int

12:01 <discocaml> <.armael.> (ah right you figured that out already :p)

12:02 <discocaml> <contificate> caml_foo1 will expect 2 arguments, as it turns out

12:03 <discocaml> <.armael.> ah, my bad, you're right…

12:04 <discocaml> <.armael.> the manual indeed mentions that you need to add a type abbreviation if you want to hide the arrow

23:41 <discocaml> <cy_tek> Hi everyone 🙂 I was just wondering if there's a reason major libraries seem to make and prefer solely Unix instead of also Windows. I notice that JaneStreet has `core_unix` and a lot of Async/Multithreading documentation/libraries seem to cater exclusively towards Unix. This is even done in one of what I can tell to be more popular books on OCaml (Real World OCaml ver 2).

23:41 <discocaml> <cy_tek>

23:41 <discocaml> <cy_tek> I was just curious if it's a lack of developers creating things for Windows, if OCaml as a language doesn't support Windows very well, or what the case was 🙂

23:45 <discocaml> <uberpyro181> ocaml support for windows is very new (roughly since the start of the year), and last i checked the support was still rather spotty / rudimentary

23:45 <discocaml> <uberpyro181> so since ocaml was unix-only for a long time, most of the resources and libraries available are in the context of unix

23:46 <discocaml> <uberpyro181> ocaml support for windows is new (roughly since the start of the year, with the ocaml 5 release), and last i checked the support was still rather spotty / rudimentary

23:48 <discocaml> <cy_tek> Ahh, okay 🙂 Thanks for the additional context! I might start looking at if there are any areas I might be able to contribute to. Are there any areas in particular that you know of that may be looking for contributers in that area?