[ocaml-platform] on the need and design of OCaml namespaces

[Daniel Bünzli]

Le mercredi, 27 février 2013 à 15:16, Leo White a écrit :
> It is difficult to provide examples of people doing something that is not  
> currently supported. Using the compiler itself as source of possible module  
> names, I see the following module names that I could easily picture  
> multiple libraries using:
>  
> Warnings, Tbl, Misc, Config, Errors, Env, Types,
> Protocol, Shell, Common, Table, Log, Options

The question is whether these things would be really linked in separately, i.e. if usage of the library does not automatically entails usage of these modules, if it does then something like -pack is sufficient. In the libraries I distribute all the examples of (manual) packs I have are of this nature (Cmdliner and React).  

The first example I hit so far where I thought about "the don't want to link everything" is this unreleased gg module where a 2D program wouldn't care about the 3D stuff. While gg.o is still only 300k, maybe it's only a sign that gg is not modular enough and that it should be factored out into gg2 and gg3 with gg3 depending on gg2 (3d usually needs the 2d stuff anyways).

I wonder if the need for namespaces is only really meaningfull for "battery-like" projects that aim at overtaking your whole source (where -pack is obviously not a solution). But now that we have build tools like opam/oasis/ocamlfind that allow us to easily specify package dependencies couldn't maybe these huge libraries modularize their design and distribute their functionality in smaller composable units ?

> I think that it is a little dangerous to judge how much people would use a  
> proposal based on how many people used its complicated and deeply flawed  
> predecessor.

I don't think it's deeply flawed, it's flawed in the hands of people that didn't understand its implication (and has historically been used by such hands). It works perfectly well for libraries in which all submodules are anyways linked in and I think that for well defined components that have a clear idea on what service they provide this happens more often than you'd think.

Daniel