[ocaml-platform] An alternative proposal for namespaces

[Alain Frisch]

On 03/20/2013 12:03 PM, Leo White wrote:
> None of the above is helped by removing "simple namespaces through
> filenames": it is all already supported by my proposal.

This is not true.  The good properties I list for a system without 
"simple namespaces" are lost if these "simple namespaces" are to 
supported by tools.

> If you don't
> like some of the aspects of "simple namespaces through filenames" then
> simply don't use them.

This does not work: as soon as a feature is supported by the compilers, 
the tools have to support them as well.  The fact that I don't use 
"simple namespaces through filenames" does not allow ocamldep, omake, 
ocamlbuild, ocamldoc, etc to not support them.  Extra features can have 
bad effects, even for people who do not plan to use them.

Moreover, removing the feature will also reduce the risk of weird 
behaviors of the compiler and user misunderstandings.  In particular, 
saying that "open namespace Foo" does not fail as soon as their is a 
"foo-*.cmi" file in one of the -I directories is fragile.  Concrete 
example: the library developers decides to change the name of one of his 
namespaces from Foo to Bar, but there are old foo-*.cmi files around, so 
the compiler does not complain upon a remaining "open namespace Foo" in 
one of the files.  It's better if the compiler has some explicit 
knowledge of namespaces which are really available (through search path 
files) than to rely on the existence of files.

> The majority of users do not require complex dependency analysis for
> generated source files. I see no reason to prevent them from using a
> convenient mechanism for defining namespaces. It is also the only
> mechanism that is really in keeping with the current design of OCaml.

I consider that the way OCaml interact with the file system has bad 
consequences w.r.t. to dependency analysis, which can be fixed quite 
easily by letting the compiler and tools know about which files are 
available.  Introducing namespaces is an opportunity to improve the 
situation, and it also makes it even more important to do so (because we 
want to support naming source files differently from compiled units, 
which breaks a property on which ocamldep currently relies).

> This should probably be a warning not an error. There is nothing wrong
> with deliberately shadowing the description of a namespace.

This is probably a matter of taste.  For me, if a library comes with a 
naming scheme for its modules, I really don't want another library to 
mess with it.  Shadowing is fragile and make the resolution depends on 
the ordering between command-line arguments.  Another source of 
potential problems which can be easily avoided.

> I don't see how they can resolve aliases manually without knowing, on
> the end user's machine, the location of all packages relative to the
> location of their package. This also hard codes the aliases, what if the
> other package moves?

First, I think it's a bad idea for a package to re-export module from 
another package.  This is just calling for trouble when user read the 
documentation of the respective libraries, or try to make sense of the 
error messages.  Providing several names for a module in a single 
package (e.g. Core..List and Core_std..List) can be useful, but I don't 
see any use for more complex operations.

Second, if this is really required, this can be done by generating the 
"search path file" during installation.

> The idea is that build systems like ocamlbuild do not *have* to support
> the "-name" argument. It is there so that the build system *can* support
> various naming conventions if it wants to. If we specify a particular
> file format for specifying names then every build system *must*
> recognise that format.

With -name, the mapping between source file names and compilation units 
is only local to the build system.  But this information is really 
useful for tools (like the current design of ocamldoc or Bisect).  Just 
providing a low-level feature to rename target files in an arbitrary way 
will make it harder for these tools to behave correctly.  Concretely, if 
I write a Makefile manually which uses "-name" as in your proposal, how 
do I inform ocamldoc about the mapping?  Same question for ocamldep.

Requiring that (in this "current namespace mode") the source filename 
correspond to the module name in the namespace will reduce risks of 
confusion and allow tools to use the existing "search path files" as a 
good source of information to relate source and compiled files.


> So either the user must write their own search path file specifying the
> name of every single compilation unit, or the build system has to
> generate it. If the build system has to generate it, how is that better
> than using a direct argument?

Because other tools can parse the file.  Otherwise, the information is 
left hidden in the build system.

The users already have to list all files in a library.  Currently, this 
information is specified in the build system itself.  If users directly 
write a "search path file" and the build system parses it (for instance 
to deduce automatically which modules to put in the library), there is 
no more work for the library author, and the information is directly 
made available to other tools.


Alain