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

[Anil Madhavapeddy]

There's one scenario which absolutely requires the ability to explicitly open a particular namespace: camlp4 code generation.

Right now, several camlp4 extensions break because they use modules from the standard Pervasives library, and have no way to explicitly state that.  If Core.Std is opened, then compilation fails.  

The two workarounds are:
- hack the build system to pass -pp options to the camlp4 generator. Painful.
- have some facility to explicitly open 'Caml_std' or 'Core_std' locally, irrespective of the current module environment.

I believe namespaces addresses the latter workaround.

-anil

On 22 Feb 2013, at 10:39, Daniel Bünzli <daniel.buenzli at erratique.ch> 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).
> 
> 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