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

[Gabriel Scherer]

Hi,

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.
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).

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:
- a design document: http://gallium.inria.fr/~scherer/namespaces/spec.pdf
- the slides of the talk:
http://gallium.inria.fr/~scherer/namespaces/consortium-talk-2012.pdf

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.

(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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130221/38f72438/attachment.html>