Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
> But .mli files do not help with the "no types in the source code" problém
It partially helps since it forces you to have types where they matters most: interfaces.
> And I did not experience any advantage of separate signature files so far,
100kLoc is already quite big! I'm starting to think I'm an outlier since a lot of people don't see the benefits :)
For me, it helps because I really don't want to see the implementation when I use an API. If I need to look at the implementation, it means the interface isn't well specified. All I need should be in the interface: types, docs, (abstract) types. And no more.
Typically, an .ml file will have more than what is exported, types won't be abstract but will have a concrete implementation, and type signatures may be missing. How would it feels like to use list if only https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.ml was available, instead of https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.mli?
Haskell tells you what is exported from a module, but it only shows you the names. To see the signatures, you need to rely on generated doc.
Arguably, since OCaml has includes, it suffers from the same problem, your ".mli" may have tons of include and it becomes harder to see what's exported without an external tool
For 5.0+ you might want to look at https://github.com/ocaml-multicore/eio for how effects can make async much more pleasant
Some of your questions might be answered in this book (free online version): https://dev.realworldocaml.org/