Here are the introductory paragraphs from its overview:
MlFront adds a Java-like package system to OCaml. The MlFront name is a homage to cfront which was tooling that translated “C with Classes” (now known as C++) into C code. Similarly, MlFront-based tools can translate “OCaml with packages” into conventional OCaml.
…
At its most basic core, MlFront gives a well-defined, consistent meaning to a module reference like AcmeWidgets_Std.Activities.Manufacturing across the domains of:
OCaml source code.
findlib libraries.
opam packages.
MlFront is Apache 2.0 licensed and is meant to be used by build systems (Dune, ocamlbuild, DkCoder) and package managers (opam). One of its critical dependencies is codept.
You can read more about MlFront in the following posts (with more coming):
Cross-post notice: The first article was posted at https://lobste.rs/s/7ghslo/overview_ocamlfront; no comments (:(). But I’d still like to get first-hand feedback on what works well in other languages, so please chime in even if you don’t feel that OCaml is your strong suit.
There has also been some activity around better package management integration into Dune too, but there is probably still a long way to go: OCaml Platform Newsletter - June 2024 - HackMD
The “benefit” of being much newer to the community is I’m completely unaware sometimes what has been tried/proposed before. Thanks for the links. I see that @gasche made a nice summary for me to follow. For example, there was a perceived impracticality (“Using long hopefully-unique names is impractical”) which I experienced early during my daily dogfooding, and which I “solved” by having a special “open__.ml” module that I talk about in the posts. It would be good at some point (sooner rather than later) for me to do a “Prior Art” write-up comparing the MlFront implementation with the proposals.
And elsewhere there is mention of “versioning” as part of “namespacing”. I do have a partially-complete versioning solution with most of the implementation already present in MlFront, but I am not sure I want to expose much of it at an API level. I think the right layer for versioning is at the build system … that is, let Dune do whatever style of versioning it likes, and allow that to be independent of how another build system like DkCoder does versioning. The only responsibility MlFront (etc.) would have is to expose a mechanism for the build system to inject the module version when needed. Anyway, that can use feedback.
and produce standalone build scripts that can be committed to source control:
$ mlfront-boot -native -o buildscript
$ ./buildscript.sh # .\buildscript.cmd is also created
$ target/BobBuilder_Std.B
I am an A!
I am a B!
On a related note, I’ve begun to implement a small part of https://gallium.inria.fr/~scherer/namespaces/spec.pdf. It is not strictly required but Namespaces.mli will be very helpful for upgrading existing projects to MlFront-style packages without changing code. That will be for a future (not soon) post.
Do you have an example of how the generated buildscript.sh looks like? Most OCaml code tends to use dune, so it’d be nice to see whether it could be integrated with dune in the future. E.g. can you call the script from within a dune rule until dune gains official support for this?
A strength of dune is the parallelism it employs. It seems quite difficult to achieve the same level in a shell script. That being said, I like the idea that, like a compiler, a build system that creates something (like a shell script) that is executed later and independent of the tool that created it.
Yes, Dune does a zillion things that MlFront_Boot doesn’t, including parallelism (and C, out-of-date checks, Merlin, etc.). That is why for DkCoder I generate dune and dune-project files rather than POSIX/DOS scripts … and that still uses MlFront as a library. But change to existing tools requires convincing and time, so I can suggest that if someone is motivated they could add a MlFront_Toplevel to generate a script file that can be run with ocaml scriptfile.ml, and also embed something like moonpool into scriptfile.ml to add parallelism. And if it isn’t clear to a motivated OCaml-er how to build that MlFront_Toplevel build system, that is a signal I haven’t documented MlFront_Boot enough.Edit: I need MlFront_Toplevel for an unrelated reason, so I’ll build it myself.
Ultimately, I’d like to keep MlFront_Boot capable of producing simple-to-audit POSIX/DOS scripts. I may even add comments and section breaks so it is more readable. So, no background jobs and no wait commands in the scripts. A nice side-benefit of the “simple-to-audit” is that MlFront_Boot should be ideal for a student learning OCaml after a semester of Java: they can focus on their source code (no configuration needed), and the ocamlc/ocamlopt compiler is not hidden from them.
There is now a new library MlFront_Top with a build tool mlfront-top that will generate self-contained OCaml toplevel script files with parallelism based on @c-cube’s moonpool library: