<discocaml>
<darrenldl> using a regular list instead of a stack would have allowed easier look back and enjoyed exhaustiveness check, e.g. stack empty not handled properly
<discocaml>
<darrenldl> (re the original solution)
trillion_exabyte has quit [Ping timeout: 240 seconds]
trillion_exabyte has joined #ocaml
mbuf has joined #ocaml
troydm has joined #ocaml
Serpent7776 has joined #ocaml
mbuf has quit [Quit: Leaving]
Tuplanolla has joined #ocaml
Serpent7776 has quit [Quit: leaving]
wingsorc has quit [Ping timeout: 256 seconds]
pi3ce has quit [Ping timeout: 240 seconds]
pi3ce has joined #ocaml
<discocaml>
<laurentt_16569> Hi,
<discocaml>
<laurentt_16569> I have some problem while porting some old Ocaml libraries.
<discocaml>
<laurentt_16569> Before I was using nums and had `open Big_int`. From what
<discocaml>
<laurentt_16569> I understood now I have to use zarith and do `open Big_int_Z`.
<discocaml>
<laurentt_16569> This works fine on toplevel but when I am trying to compile it with
<discocaml>
<laurentt_16569> `ocamlc -I +zarith zarith.cma file.ml` I always get an `Error: Unbound module Big_int_Z`.
<discocaml>
<laurentt_16569> What I am doing wrong?
bartholin has joined #ocaml
cr1901_ has joined #ocaml
waleee has joined #ocaml
cr1901 has quit [Ping timeout: 272 seconds]
tremon has joined #ocaml
<discocaml>
<hockletock> `-I +foo` is for libraries included in the standard library, which zarith isn't; try either `ocamlfind ocamlc file.ml` or use `ocamlfind query -i-format zarith` for the appropriate argument to locate zarith
trillion_exabyte has quit [Read error: Connection reset by peer]
trillion_exabyte has joined #ocaml
waleee has quit [Ping timeout: 268 seconds]
<discocaml>
<yawaramin> (or try using dune)
<discocaml>
<laurentt_16569> @hockletock thanks explictely adding the path of zarith works. It would have been nice if `-I +zarith` would have raised a warning 😉
<discocaml>
<tornato> Does anyone know of any tools for generating SBOM reports of ocaml code or if there are any forks of syft with Ocaml integration
<discocaml>
<tornato> Does anyone know of any tools for generating SBOM reports of ocaml deps or if there are any forks of syft with Ocaml integration
<discocaml>
<faldor20> So I kind of hate .mli files. I think they are just much worse than having an .ml file and being able to set things as public/private.
<discocaml>
<faldor20> I was thinking of trying to make a dune preprocessor that generates mli files from ml files with special `public`/`private` annotations.
<discocaml>
<faldor20>
<discocaml>
<faldor20> I'm wondering what folks think of that/if there is any prior work.
<discocaml>
<hockletock> You'll lose odoc for document generation
<discocaml>
<limp.biskit> is odoc invoked before ppx?
<discocaml>
<limp.biskit> i often work backwards from a generated mli when i want to publish/stabilise a module
<discocaml>
<deepspacejohn> One limitation you'll run into is that type annotations are interpreted differently in ml versus mli. In mli polymorphic type variables are universally quantified whereas in ml they aren't.
<discocaml>
<deepspacejohn> that may be solvable by the preprocessor but it will definitely have to be considered.
vb has quit [Ping timeout: 240 seconds]
vb has joined #ocaml
<discocaml>
<sim642> There's more to interfaces than public vs private. For a type declaration, the interface can make it abstract. So it's definition is private but declaration is public in some sense
<discocaml>
<sim642> Not to mention private types in OCaml as they already are, which provide yet another level of exposure
<discocaml>
<sim642> mli files have a benefit for separate compilation speed as well. If you have one and only change the implementation, everything transitively depending on it doesn't need to be recompiled because it cannot have changed the public interface
tremon has quit [Remote host closed the connection]
tremon has joined #ocaml
waleee has joined #ocaml
cr1901_ is now known as cr1901
oriba has joined #ocaml
troydm has quit [Ping timeout: 272 seconds]
wingsorc has joined #ocaml
<dh`>
that's not actually true (compilation speed), the compiler looks under interfaces sometimes
<dh`>
however, trying to get rid of .mli files is a mistake
bartholin has quit [Quit: Leaving]
<discocaml>
<hannes6838> I don't think there is SBOM output for OCaml dependencies. But there has been quite some work on `opam switch export --full --freeze` which outputs all opam dependencies with hashes and other metadata. This is in opam-file-format, not in SBOM (I believe SBOM is json, isn't it) -- but it could be easy to transform. I've used the `opam switch export` as basis for reproducible builds with `orb` https://github.com/robur-coop/orb
<discocaml>
<hannes6838> Feel free to get in touch via the issue tracker or eMail if you have clear requirements / want to investigate SBOM & OCaml further.
waleee has quit [Ping timeout: 268 seconds]
<companion_cube>
You could use nix I guess
waleee has joined #ocaml
trillion_exabyte has quit [Ping timeout: 268 seconds]
trillion_exabyte has joined #ocaml
tremon has quit [Remote host closed the connection]
<discocaml>
<yawaramin> does nix output sbom reports?
<companion_cube>
There's a nix-sbom tool i believe!
<dh`>
I would like to point out that using a generic term like "bill of materials" for any specific format is abusive :-/
<discocaml>
<shon_18152> module types/signatures/interfaces should be distinct and separable from module implementations or else you don't have a proper (which is to say, ML) module systems. See the seminal "Modules for standard ML" (https://dl.acm.org/doi/10.1145/800055.802036) and cited work therein for a thorough explanation of why this is required for proper modularity.
<discocaml>
<shon_18152> The need for `.mli` files in particular just follows from OCaml's choice to make the contents of an `.ml` file define a module implementation. IMO, going SMLs route (where any module in a file needs to be declared as a module) instead would have been just as workable, and nicer in some ways but more of a pain in others. But this still means specifying modules interfaces separately from module implementations. That's stated as fact, which I
<dh`>
It's not _required_. There are many possible concrete syntaxes for defining module interfaces.
<dh`>
Module interfaces defined by in-module annotations are not inherently either more or less expressive
<dh`>
ML-family languages _traditionally_ have separate interface definitions
<discocaml>
<faldor20> I think I've maybe given a slightly incorrect impression. I don't want to remove modules altogether, I understand and appreciate their benefits for abstraction and allowing changing implementation.
<discocaml>
<faldor20>
<discocaml>
<faldor20> My point is just that most mli files aren't using any fancy module system features. Mostly in my experience they are just a way to make things public and private.
<discocaml>
<faldor20>
<discocaml>
<faldor20> Also they mean that comments and docs end up separated from the implementation. Which is really silly and makes code much harder to read.
<discocaml>
<faldor20> But I do see the issues with preprocessors not having type info.
<discocaml>
<yawaramin> interfaces allow making abstract types. this is not a fancy module system feature, it's a very basic technique in MLs. imagine if someone told you that encapsulation and information hiding is an advanced feature of OOP 😉
<discocaml>
<shon_18152> > Module interfaces defined by in-module annotations are not inherently either more or less expressive
<discocaml>
<shon_18152>
<discocaml>
<shon_18152> If you cannot write the interface separately, then how could you separate the interface from the implementation? You could have sugar that would generate an interface from an implementation (and in fact we have that via `module type of`), but I don't see how you can have the many-to-one relationship between interfaces and implementations we need for proper modularity without support for interfaces as distinct language constructs.
<discocaml>
<shon_18152> Then if you have those already, afaict, the question about having some sugar you can add inline to an implementation is a question of how much you want to clutter your surface syntax with doohickeys that add 0 additional expressivity.
<discocaml>
<shon_18152> > My point is just that most mli files aren't using any fancy module system features. Mostly in my experience they are just a way to make things public and private
<discocaml>
<shon_18152> The opposing view is that they allow you to read the public specification of a module, both its types and documented behavior, without the clutter of implementation details that should be abstract and not relevant (if all is well documented and in order, bit "if" there XD ).
<discocaml>
<shon_18152> *big "if"
<discocaml>
<shon_18152> You can still but comments in your implementation, but for a sealed module, IMO those should be comments to devs who work on writing the module and not documentation to users of the module's public API.
<discocaml>
<shon_18152> Oop, copied the wrong line there. I meant to be replying to "Also they mean that comments and docs end up separated from the implementation. Which is really silly and makes code much harder to read."
<discocaml>
<shon_18152> Well, maybe I'd come around on this. I do feel like the identification of files with implicitly declare module implementations has a fair number of awkward bits. Honestly I probably prefer the SML approach. A middle ground might have been to require that all files have a single top-level module declared, in which case the interface declaration would just be the usual signature on a module declaration rather than needing a separate file....
<dh`>
docs don't belong in source files in any event
<discocaml>
<shon_18152> (But I would NOT prefer to have new java-like keywords for visibility on implementations added to the language in any case.)
<dh`>
realistically, for modules that are units of separate compilation, there's never a many-to-one relationship and it works fine to build the interface from annotations
<dh`>
the real question is, is that the way you want to define annotations?
<dh`>
er
<dh`>
define interfaces
<dh`>
and I would say that it is not, separate interface files are good
<dh`>
the amount of cutpaste from the interface file that's sometimes required is a problem, but it's a fixable problem (it's e.g. fixed in coq)
<dh`>
the real problem with ML-style modules is that they're mixing a data structure/object mechanism with a separate compilation mechanism and that creates all kinds of unnecessary mess