Hi, all! A while ago I came across a blog post discussing how one might compose together different modules without using module types or functors. Instead it was relying on the untyped nature of module linking to supply different module implementations that would all adhere to the same implicit interface.
Does that ring a bell for anyone? All my attempts at Googling this have failed so far. Thanks!
Currently, such layout can be handled by dune with virtual-modules (no variants). The first library, as far as know, which uses this " trick" (we initially talked about “linked-trick”) is ptime/mtime to be able to compile the project in native and with js_of_ocaml - So, the *.cmx is chosen depending on the target.
It is the same “layout” for digestif/checkseum which use dune. By this way, we are able to use them with js_of_ocaml too. This is the most interesting case where usability can become complex. Outside the scope of dune, it’ s easy to have a linking error because you did not specify the right *.cmx/implementation at the link-time.
About maintainability, it can be a problem specially for digestif or checkseum where you must maintain twice implementation. So I prefer to advise to not use virtual modules or use them into a restricted area (instead of using them systematically instead of functors).
I’m no longer sure if it did the cmx hidding to get a backend independent cmi but as far as I remember OCaml’s threads library in their posix vs (now removed) vm thread incarnation used link time implementation selection long before I did; at least that’s were I took the technique from.
One of the drawbacks of doing it purely at link time is that for native compilation it inhibits cross-module inlining for the library.
For applications it’s a better idea to have two libraries that simply implement the same interface and the client then simply compiles and links against the library it needs.
The problem with this is that it doesn’t scale for libraries that want to depend on the interface regardless of the implementation: they need to replicate the implementation choices for themselves even though they do not care and need to be changed to explicitly support new implementation when they show up.
Thanks! Not the blog post I was looking for, but it’s actually better since the virtual-modules page shows that this technique now has a name and is well supported by the build tool, whereas the blog post was presenting it as some sort of a hack.