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

[Alain Frisch]

On 02/27/2013 03:16 PM, Leo White wrote:
> It is difficult to provide examples of people doing something that is
> not currently supported. Using the compiler itself as source of possible
> module names, I see the following module names that I could easily
> picture multiple libraries using:
>
> Warnings, Tbl, Misc, Config, Errors, Env, Types,
> Protocol, Shell, Common, Table, Log, Options

It's a good example indeed.  I interpret this situation as the 
consequence of the fact that the compiler has been designed as a 
program, not a reusable library.  The "long filename" approach would be 
to call the source files e.g. ocaml_location, ocaml_env, ocaml_types, 
etc, and use locally, in the source tree, a ocaml.ns file to keep short 
names (Location, Env, Types) in the source code.  Note that implementing 
this refactoring would be very light (rename files in the repository, 
create the .ns filem, adapt the Makefiles accordingly).

A third-party tool could use long names like Ocaml_location, Ocaml_env 
(or explicitly alias those modules to shorter names locally).  But 
indeed, this might be a case where it would make sense to "open 
ocaml.ns" locally, only in, say, in given function of the third-party tool.

>> use Xmllight.parse and Xmlm.parse (although it is not clear that this
>> will happen in the same module), but you're not going to open Xmllight
>> or Xmlm globally in your unit.
>
> But I might open Xmlm and Json (an imaginary json parsing library) in
> the same unit.

I don't think I'd ever want to open such modules globally (maybe only as 
a local open in a few functions).  It would make the code more obscure 
(what does "parse" do?), and is likely to create clashes.

>>> Currently, a file using a library that does not use pack will simply
>>> launch straight into using modules with short names that give no
>>> indication of their origin.
>>
>
>> So I don't agree with the opinion that -pack is currently the only way
>> to avoid clashes!  It would be useful to get some statistics about the
>> use of -pack in OPAM.
>
> I think that it is a little dangerous to judge how much people would use
> a proposal based on how many people used its complicated and deeply
> flawed predecessor.

I was referring to your "currently" sentence.  I know some libraries use 
-pack, but luckily a lot of libraries don't do that, and I believe it is 
a useful piece of information for this discussion to get some statistics 
about this.



Alain