Hi,<br><br>Since about a year now, there has been a intermittent discussion ongoing on the idea of introducing "namespaces" to the OCaml language. The basis for discussion are some pain points of the current behavior of the current implementation (all modules live in a flat space that is defined by the search-path (-I command) and not very resilient to change), but there have been fairly different ideas about how to best solve those problems, or even what "namespace" means.<br>

The current flat-module-space has mostly been felt by distributors of largeish codebases designed not to be used in isolation, but required by users code, in particular set of libraries for OCaml (in particular JaneStreet Core or Batteries, and possibly components from the future OCaml platform).<br>

<br>I have worked on these issues last year with Didier Remy, and also Fabrice Le Fessant and Nicolas Pouillard, and made an presentation at (the informal part of) the last meeting the Caml Consortium. Here are a few documents we we have written in the process:<br>

- a design document: <a href="http://gallium.inria.fr/~scherer/namespaces/spec.pdf">http://gallium.inria.fr/~scherer/namespaces/spec.pdf</a><br>- the slides of the talk: <a href="http://gallium.inria.fr/~scherer/namespaces/consortium-talk-2012.pdf">http://gallium.inria.fr/~scherer/namespaces/consortium-talk-2012.pdf</a><br>

<br>While I think the core problems with the current compilation unit lookup system are rather consensual, there is little agreement on what a reasonable extension for the language or implementation would be, or if it is even needed at all. The documents above take an intentionally "rich" approach of the question, presenting a formal framework and language designed to be rather expressive. It would be desirable to isolate a simpler feature set that would cover the practical needs, but this needs to a careful examination of the use cases, etc. I think people working or interested in the OCaml Platform may have interesting inputs on the problems and use cases at hand.<br>

<br>(A good example of the design trade-off involved is: who should have the responsibility of choosing the names by which the OCaml user refers to modules / software components on her system, the user itself or the component provider? Letting users name things adds flexibility but also complexity. Having a global shared namespace (eg. opam) makes the overall design simpler, but also may also forbid some potentially interesting use cases, such as users keeping version-pinned or modified versions of their dependencies locally, and being able to explicitly refer either to the standard version or the local version of a package. Do we want to forbid that? Allow to pick one choice or the other in the global build system of the developer's project? Let the developer use and link both standard and local versions at the same time in a program, to compare them and make tests, or if one dependency uses the standard version, and the other the local one? Besides design trade-offs, there are also underlying implementation questions, as the current OCaml linker has a rather inflexible semantics in this regard.)<br>