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

[Wojciech Meyer]

Hi,

I want to say that (not finished yet) proposal looks good to me. I like
the idea of being able to structure the environments into tree.
The reason why I think we should use hierarchy is:
- ability to structure several libraries into same "shelves" - looking
what Haskell does [1]: Control.Arrow or Data.Array. It will help to
provide one and consistent library for the platform. It does not
necessarily require (but enables) to use "provenance" style of naming
(e.g. Java convention)
- it enables us to pack some of the platform specific modules into
single name under some hierarchy, consider:

Win32 # System # Unix
Unix # System # Unix

now we are able to conveniently merge appropriate one of these during
compile time.

I'd like to emphasise that we would need to encourage people in a social
way to use the hierarchies wisely, and have some fixed conventions for
the community projects. One way to do this is the Platform itself - when
it will come with pre-bundled hierarchy people will start putting their
libraries into right shelves.

I'm a big fan of the DSL approach, and the spec have clear semantics
regarding namespaces - namespace a name for an environment.

I don't think I have anything other to say, beside that so far I like
it. Looking forward having more input in the proposal.

--
Wojciech

[1] http://www.haskell.org/ghc/docs/latest/html/libraries/


On Thu, Feb 21, 2013 at 1:08 PM, Gabriel Scherer
<gabriel.scherer at gmail.com> wrote:
> 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.)
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>