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

[Martin Jambon]

On 02/22/2013 02:39 AM, Daniel Bünzli wrote:
> This may be a silly suggestion as I'm not sure I'm really convinced
> by the absolute *need* for namespaces (I'd rather not have an
> additional concept in a language that I already find sufficiently
> complex to my taste).

Namespaces allow a single organization to provide a collection of 
optional packages named consistently (e.g. String, Json, Http, 
Elasticsearch, ... instead of having to invent silly names for each of 
these because there are gazillions of implementations out there).

A namespace identifies a software vendor (an organized group of people), 
who can manage the name of their packages and modules unilaterally, i.e. 
without having to worry about the rest of the world (which includes 
competitors and people who just won't talk to each other).

It is different from the concept of module, which cannot be split into 
optional packages.


> However it strikes me that while it seems to be agreed upon that a
> simple mechanism like `-pack` solves the problem albeit not in a
> technically satisfying way, the worked out proposal seems to
> skyrocket into complexity. The best way to avoid
> bureaucracy/complexity is not to introduce the tools to be able to
> manage it...
>
> So if the problem is `-pack` is not good enough because it produces a
> huge `cmo`, why not just try to find a corresponding concept workable
> with `cm[x]a` ?
>
> Here's a proposal --- from a user point of view, I'll let the
> compiler hackers comment on how/if this could be workable.
>
> Introduce `cmia` files that bundles the `cmi`'s of a `cm[x]a` with
> the corresponding file name. The name of the `cmia` file (and hence
> of the `cm[x]a` file) defines your toplevel module name à la `-pack`.
> Make it even be backward compatible in the sense that if there's no
> `cmia` for a `cm[x]a` the modules are accessed as before. Now you
> have a kind of `-pack` that work with `cm[x]a`.
>
> Best,
>
> Daniel
>
> P.S. flat vs hierarchical, I'd also rather go flat.
>
>
> _______________________________________________ Platform mailing
> list Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>