[ocaml-platform] An alternative proposal for namespaces

Alain Frisch alain.frisch at lexifi.com
Thu Mar 21 12:16:57 GMT 2013

On 03/21/2013 12:02 PM, Leo White wrote:
> always use search path files instead of directories (which is
> what you are proposing anyway).

I'm planning to use search path files for namespaced modules only, 
because this will be the only good way to do dependency analysis for 
them (good support for generated files and "simple namespaces" requires 
heavier interaction between ocamldep and the build system).  But I'm 
still planning to use non-namespaced modules for most of our code base, 
and the current combination of -I directories and omake+"ocamldep 
-modules" works really well.  The problem is that your proposal will 
force ocamldep to scan directories for "simple namespaces" as soon as I 
use -I directories.

Even if in your proposal search path files are orthogonal to namespaces, 
they only become critical in presence of namespaces.  I think it's 
important to continue the current mode of operations (with -I 
directories) while allowing to gradually start using libraries using 

It seems kind of weird to me to say that as soon as the project will 
have some generated source files, the build system should behave 
differently and produce a temporary search path file only for dependency 
analysis, while otherwise it would use a different mode of ocamldep. (I 
still don't see how this mode would work in presence of ad hoc "-name" 

> Note that using an external library that uses "simple namespaces" will
> not cause your own builds to have this problem.

Well, I will either have to create search path files myself (while they 
could easily be shipped with the external library) or use -I to these 
directories (in which case ocamlc/ocamldep will start inspecting the 
file system, potentially creating the problems I've described if I need 
to locally patch that library).

>> The average user who creates a library to be used by others will need to pick a good namespace
>> name and list which files constitute the library.
> This is not the case. I do not currently have to write a list of files
> in my libraries. As I said, it depends on which build system you use.

Can you share with us how you specify the content of the library in your 
build system?  I can imagine relying on some kind of other conventions 
(filename again or directories?).  But anyway, at some point, you will 
need to pass a list of modules to "ocamlc -a", so you have the 
information readily available and it would be trivial to generate 
automatically a search path file, shipped with the library, for the 
convenience of the library clients who might want to avoid using "simple 
namespaces".  And if you do that, there is no point not using that 
search path file instead of relying on the built-in support for "simple 
namespaces" in the toolchain.

> Note that you don't just have to write these files after you have
> finished the library, you must maintain them throughout development.

If your build system is clever enough to discover the content of a 
library automatically, it should be possible to generate that file as well.

> We should not be looking to design the system that is the easiest for
> the maintainers of omake, we should be looking to design the system that
> is best for the users of OCaml.

Support in omake is only an illustration of possible collateral damages 
of introducing "many ways to do it" in the design.  (And even for omake 
itself, the problem is not only for the maintainers of omake, since I 
suspect more users with large code bases have their local version of the 
build rules for OCaml.)

You don't know about the consequences on all existing code bases of 
adding support for "simple namespaces".  I'm pretty much convinced that 
it will make the life more difficult, not simpler, for users with large 
code bases.  I also believe that the overhead of forcing to use search 
map files for namespaced modules, i.e. mostly for people shipping 
libraries, is negligible and will have nice side effects (fewer problems 
that today).

I won't continue on this topic of "simple namespace" vs "search path 
files"-only for namespaces, because we don't make progress and it 
doesn't seem we are going to reach an agreement.  Let's agree to 
disagree on this point.



More information about the Platform mailing list