00:06 <discocaml> <barconstruction> dh, by sealing I meant

00:06 <discocaml> <barconstruction> module M : sig

00:06 <discocaml> <barconstruction> ...

00:06 <discocaml> <barconstruction> end

00:06 <discocaml> <barconstruction> = struct

00:06 <discocaml> <barconstruction> ...

00:06 <discocaml> <barconstruction> end

00:06 <discocaml> <barconstruction> And by "checking that a module implements the signature" I meant in a non sealing way, something like

00:06 <discocaml> <barconstruction> module M = struct ... end

00:06 <discocaml> <barconstruction> module M' : sig ... end = M

00:06 <discocaml> <barconstruction>

00:06 <discocaml> <barconstruction> Here M' is not supposed to be used anywhere else it is just a compile time check that the module provides the functionality you want it to, guaranteeing that it can be used at certain points in the program (even if it isn't currently)

00:06 <discocaml> <barconstruction>

00:06 <discocaml> <barconstruction> It is a subjective distinction to say that one is more valuable than the other, my reasoning is that it's less common to have multiple modules implementing the exact same exposed functionality, but more common to have multiple modules which implement at least so much functionality at the client side point where they will be used.

00:29 <discocaml> <yawaramin> `module _ : S = M` also works

00:50 <dh`> ah, I see what you mean

00:52 <dh`> not sure I agree though, for separate-compilation modules you always want sealing (otherwise there's little point)

00:52 <dh`> and in most other cases you're doing functor works and in those it is also often highly desirable to seal off the internals

01:08 <discocaml> <limp.biskit> does containers have an equivalent to Base.List.split_n?

01:14 <discocaml> <barconstruction> I think we are partially on the same page about functors. A functor cannot access any part of the module it relies on beyond what is declared in the interface specified by the client (the author of the functor) and I think that interface should be written explicitly as a signature.

01:14 <discocaml> <barconstruction> I agree that "it is highly desirable to seal off the internals" but one can leave that to the functor author who writes an interface specifying what the module type of its argument should be.

01:14 <discocaml> <barconstruction>

01:14 <discocaml> <barconstruction> My point is more about the principal signature for the module that it exposes to the rest of the program.

03:36 <anadon> dh`: I'd like to use your split3.ml wholesale in my project, copyright to you GPLv3 or similar in a standalone file. Is that OK with you? I'd add attributions at the top as usual and code would live at https://gitlab.com/anadon/detect_programs_called_from_script

09:26 <discocaml> <contextfreebeer> maybe https://c-cube.github.io/ocaml-containers/3.13/containers/CCList/index.html#val-chunks ?

19:37 <companion_cube> wow, JST is now using OCaml >= 5.1 in base!